It's great you added file locksmith to powertoys but that should be a built in OS feature for many, many years now.
The actual interesting discussion, to me, is why Microsoft won't show WHO is dangling the handle open when the user tries to interact with a file via Windows' UI. To understand that, we have to look at a BSOD change Microsoft made in Windows 8:
In Windows 2K, XP, Vista, and 7 the BSOD would tell you exactly WHO was causing your BSOD (i.e. which module). Which was incredibly helpful, when you could see it was a e.g. Creative sound driver, or Nvidia graphics driver. Then in Windows 8/8.1 they went to the "sad face" simplified BSOD screen. From then on in order to see which module it originated in, you had to load the mini-dump into WinDbg (which almost no users would/could do).
What I am saying is: Microsoft went out of their way to shield their partners (OEMs/hardware vendors) from criticism with that BSOD UI change. So it seems unlikely they'd make a change to the "File Locked" UI that would essentially do the same thing: Open up their partners to criticism for their [bad] software (e.g. anti-virus/anti-malware/corporate compliance/etc).
Then tack on that Microsoft's own software may be some misbehaving software; and they'd essentially be telling on themselves. OneDrive in particular, I've seen in that list a lot (but I could write paragraphs on what a turd/abandonware OneDrive is).
That's one reason why they removed it, because it was causing end users to blame vendors/MS when they often had nothing to do with whatever the problem was.
Ultimately to determine the underlying root-cause you'd still need to dig this same information out, and all they've done is moved the starting line behind several walls. In essence adding extra work, without solving this edge case/issue.
Regardless of if the information is in the BSOD, Event Log, or only via WinDbg, understanding the information relies on the expertise of the person reviewing/contextualizing it. They've gone out of their way to make contextualizing it harder.
For example, to determine if it is a direct failure or an associative failure (e.g. RAM failing causing different BSODs in unrelated modules), you want that context to be obvious. But without the module being in the Event Logs, you're now loading up half a dozen MiniDumps in WinDbg to find that same very key information - which people may miss or fail to do.
What I am saying is: If we believe that excuse (which I don't), they've done absolutely nothing to address it and just made that same problem worse with their childish games.
On Windows a file that is open in an application cannot be moved, plus it won't tell you which process has it open. Yes you can use some sysinternals tool but this is basic info that should be immediately available without installing some additional tools.
This makes me wonder, what happens [EDIT: on Windows] when a program uses a file, which more than a single hardlink points to, and you want to remove one of them. Does it matter, through which hardlink the file gets opened or are all the hardlinks prevented from being unlinked?
What you can't do is modify a file that's executing (program or library), then you get ETXTBSY.
> What you can't do is modify a file that's executing (program or library), then you get ETXTBSY.
Why can't you? Couldn't it do the same thing and just keep it in memory?
Edit: Actually on my system, I can start a program, unlink it and keep using it just fine. I wonder what case you are referring to.
ETXTBSY isn't even descriped in unlink(2), but it is in unlink(3posix): ETXTBSY - The entry to be unlinked is the last directory entry to a pure procedure (shared text) file that is being executed.
Really, it’s just an overly fluffy guide for using Sysinternals utilities to help fix the issue. With a heading that is criminally click-baity.
If so, does anyone know a fix for it?
At most I use GNU/NT.
In my specific case it was to save youtube videos when it was still a flash player. the video would be cached in a file but that file would be inaccessible because it was "open" hobocopy to the rescue. On linux it would make then delete the file depending on the open file descriptor to keep it around. The way to save it was to relink another name onto the inode. I can't quite remember but on linux I think you could use a /proc entry to get that inode and on obsd I would use fstat to find it and fsdb to make the relink.
As a unix aficionado I despise windows open file locking with a passion. Sure I understand it is probably more correct, An open file could be in any sort of corrupted state the only safe thing to do is default to single access and locking. But it is far more respectful to the user to just let them grab it whenever they want to. corruption be dammed.
no-name-here•1h ago