Feature Request: Unlock File

When a file (or files) is locked during a replace/copy/move/etc. you normally get the standard "this file is being used by another process" dialog; in most cases, I end up having to run either UnlockIt or Unlocker, and then restarting the replace/copy/move.

Would love if this ability was built right into DO. It could be a tool that can be called separately, as well as a convenient button right on the dialog, such as this mock-up:

Screenshot

We are not likely to add this as it is an extremely bad idea and can result in random files being corrupted without you knowing anything happened.

See: Raymond Chen Discusses Cascading Errors from Forcing Handles Closed (Edit 2023: newer url.) from MS TechNet for an explanation of why you should not use 'unlocker' tools.

It is better to just kill the process if you really have to (although that is not a great idea either), or, better, use delete-on-reboot, if there is no way to find or close the program that is holding the lock.

If you run into situations where you need an unlocker so often that you want an unlocker, something else needs fixing. Better to fix the cause of the problem than add a new problem! :slight_smile:

It would be nice to have this functionality in certain situations, such as when you need to swap patched uxtheme.dll or something like this. :wink: But, definitely not really needed on everyday bases. I don't think it's worth getting into this for such rare cases, either.

Using unlocker on a DLL which is in-use is probably a good way to crash processes which had the DLL loaded. Replacing the DLL on reboot (which Opus or other tools can do) is safer, and I'm guessing you don't need to patch the DLL often.

You are right. But would you please be so kind to give us some briefs on when and how it is happening? I remember I saw Opus request or notification, for a few times, that it would replace the files on next reboot but I don't really understand how it works?

To my understanding, when a file is locked by a process, you can just rename the locked file (i.e. a locked .dll) which will still keep the handle open to the process that is using it. So, for example, if you need to replace Cartman.dll but it's locked, you rename it to something like Cartman.dll.old, then you can copy the new Cartman.dll into that folder without issue because cartman.dll.old is still the one in use by the locking process.

My guess for DO is that it probably just does something similar; plays a sort of rename game, so to speak. :slightly_smiling_face:

Are you sure? I would not expect that to work. If wrote an app that locked a file, because the app is using it and I don't want you messing with it I would not expect you would be able to rename it. If I have the name in memory and you renamed it, then I try access it, it would fail.

There are a few methods of asking windows to replace file on boot. The gets around the issue by performing the action before it can be locked again. The ones I have seen all work similarly. you register the actions needed to be done on boot. When windows reboots it performs them for you.

Some fun reading on the topic.
https://support.microsoft.com/en-au/help/181345/how-to-replace-in-use-files-at-windows-restart

Yep. I've done it probably hundreds of times. "Locked" just means another process has a handle open to it. Renaming the file doesn't break the "connection" to the "locking" process. Try it sometime.

I forgot to mention (I just assumed it was common sense) that the new file that was copied over in place of the old, renamed file, still won't work in the main process until it's restarted though, since it's still using the handle to the old (renamed) file.

I guess it depends on the type of lock.
image

//C#
var name = @"D:\temp\locktest.txt";
var s2 = new FileStream(name, FileMode.Open, FileAccess.Read, FileShare.None);
Thread.Sleep(int.MaxValue);

Yes, it depends in the lock type.

Programs can lock files against being renamed, although DLL loading usually doesn't (maybe it arguably should, but that's up to Windows).

Opus only renames things if you choose the Rename New or Rename Old option. The copy-on-reboot option is offered for exe and dll files (I'm not sure of the exact circumstances off the top of my head) and uses the Windows API for moving files during a reboot. (Ultimately via the PendingFileRenameOperations registry value, which the Windows API manages.)

There are copy/rename/delete-on-reboot command line tools you could add to an Opus button to do similar things on demand with any file type. I wrote one myself but don't seem to have put it online. I can upload it if people want it, but I'm guessing there are similar tools already, (maybe nircmd.exe or SysInternals do it), as there must be a reason I didn't put mine online.

Yep. Try this; run DO, then go into it's folder and rename dopus.exe to dopus.exe.OLD while it's still running. :slightly_smiling_face:

I think more often than not, the handle isn't locked from being renamed. Trying to actually delete the locked file isn't do-able though (try deleting dopus.exe while it's running).