Hacker News Reader

Comment by apankrat | Hacker News Reader

This is mine. I was meaning to do a Show HN post for it actually, just was waiting for the weekend :)

I've been using this internally for several months. For local deletes YMMV. There seem to be some sort of central lock in the NTFS driver, so the speed up comes from being faster with scanning and generally idling less. For freshly mounted fast drives you may see a speed up of 1.5-2.5 times, but in other cases it will be just 10-20%.

However for remote deletes this tool is really great. Due to the network latency, single-threaded deletes will spend most of their time idle - a request needs to get there and then back before the next one can be fired. But using threads allows to have multiple requests "in flight", forming a queue if needed, so the remote end is always doing something. A typical speed up for a LAN is around 2x, and for VPN links this should be even higher.

In any case, AMA.

View on HN

One of these days I hope to get a peek at how you build UIs - you've got some of the best looking software for Windows.

Thanks, appreciate the compliment, but there's not much to it really. Do version A, use it, change what's off or annoying, rinse and repeat. At some point it always converges to a stable point.

Pretty much the only criteria is to remove friction from fast paths and add some where safeguards are needed.

Thank you for sharing. You write:

> The source is incomplete, because it depends on several libraries that are not a part of this distribution. However, with an exception of simple_work_queue, these libraries are simple Win32 API wrappers and their functionality should be fairly obvious from their usage.

Just curious - if they're trivial wrappers - why not share them?

A couple of reasons.

It takes time to prep a public release. Review the sources, comment them, check formatting, add docs, legalese, build instructions, etc. I really don't like publishing stuff that's not in a proper order.

Second is that a public release needs to be maintained and this complicates our own workflow. We can, in theory, do a release and then abandon it, but it doesn't seem like a right thing to do.

First of all, great piece of software thanks for sharing it. Secondly re: releasing then abandoning some subset of code being “not the right thing”, I would submit that as a user I’d much prefer abandoned code than unreleased code. Please consider just slapping a disclaimer on it and releasing it.

will it delete files even if open in another process? this is my main bugbear with windows file deletion: it won't delete it and you need special tools to track down the process that has the file open

Depends on how they are opened.

If they aren't opened in FILE_SHARE_DELETE mode, then they will in fact be locked against deletion... because that's exactly what file's current user wanted. Force-deleting a file in this case is not the wisest thing to do.

[1] https://docs.microsoft.com/en-us/windows/win32/api/fileapi/n..., Ctrl-F for FILE_SHARE_DELETE

Which is the right thing to do and the approach taken in all non-UNIX clones.

In any case, since ages one does not need special tools, resource monitor listing of open handles is enough.

It's the right thing to give an error that some process has the file open but never tell you which process that is?

It might not be the most user-friendly way, but sure tops removing the file altogether.

That’s an UI issue with the tool.

The underlying behavior is correct though - people with open handles have the priority unless they have explicitly stated that deleting a file while they use it is OK.

What tool? That's windows' behavior. I would agree that locking a file and preventing deletion is good or possibly queueing a file for deletion when it is free, but windows does not handle this scenario well.

Telling you what process has a folder or file open should be added to windows explorer. It’s hard to explain why it isn’t.

A workaround to this is to use Process Explorer[1] to search for the filename, then kill the process that has a handle with that file name.

[1] https://docs.microsoft.com/en-us/sysinternals/downloads/proc...

Reply on news.ycombinator.com