It feels like the article is repeating information from some other source, but I don’t see such a source linked? (also note that this site is not associated with Microsoft.)
But they can't be bothered to tell which process is holding it, not even a damn PID. C'mon guys, bare minimum here, and this issue has been there for decades.
It's great you added file locksmith to powertoys but that should be a built in OS feature for many, many years now.
Maybe the Restart Manager API (RmStartSession/RmRegisterResources/RmGetList) can return the list of processes that hlod a file open. Is available since Vista. The Shell UI just doesn't call it.
For most here, I don't think this article contains new information.
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).
On Linux if a file can't be edited because some process is holding it open you can just mv the file to /tmp and create a new file in its place. The process that has it open is unaffected because the handle is independent of the path.
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 issue was what had me give up on windows forever and its been around since forever. There are many situations when there is just no way to release files except restart. When the basics don't work nothing else even matters.
On a possibly related issue, is this the same thing that cause the 'USB drive is still in use' message when you try to eject a USB drive even when every application is closed?
On a drive there is also the filesystem, which might not be finished with its work. When a program writes to the disk it gets buffered by the OS/filesystem driver first, so that the program can finish, before the data is actually on the disk.
So there is no fix, because there is nothing to fix. If you remove the device before the OS tells you you can, you risk missing data or corruption.
10 comments
[ 3.0 ms ] story [ 39.8 ms ] threadIt'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).
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.
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?
So there is no fix, because there is nothing to fix. If you remove the device before the OS tells you you can, you risk missing data or corruption.