Using Unlocker In The Command Editor

I use a popular Unlocker utility that lets you free files still in use by other appilcations.

I have spent some time trying to do my first script so I can put a button on the toolbar and also set up a keyboard shortcut.

Currently, unlocking files works with this but it will not unlock directories. (Nothing happens when I execute this against a directory.)

Can any of you experts help? What could be wrong?

Here's the code in the command Editor:

if exist "%TEMP%\opus_file_list.txt" ( del "%TEMP%\opus_file_list.txt" ) @nofilenamequoting echo {filepath$}>>"%TEMP%\opus_file_list.txt" echo FILE LIST: type "%TEMP%\opus_file_list.txt" C:\Program Files\Unlocker\Unlocker.exe %TEMP%\opus_file_list.txt /O /L

You should use {allfilepath$|filem} to generate the list of filenames. You'll find it a lot more reliable/simple:

You can simplify the whole command to this (note that I've added the quotes you were missing as well):

"C:\Program Files\Unlocker\Unlocker.exe" {allfilepath|filem} /O /L

You may find that fixes the problem with folders as well. It's probably Unlocker.exe being confused by the way Opus puts a \ on the end of folder paths. When you write the paths to a temp file Opus doesn't seem to do that. (When not writing to a tempfile you can use "noterm" like I've used "filem" above to suppress the slash.)

Aside: I find it odd that people routinely unlock files that other programs have open so much that they need to make buttons which make it convenient to unlock lots of files at once. Unlocking is dangerous and shouldn't be done routinely as it could crash whatever has the file open or lose data if the file is being written to. I don't think I've used Unlocker this year and I find it odd that it gets mentioned so much. It's a useful tool in emergencies but I'm surprised/worried about people using it routinely.

I have to use unlocker when a directory contains invalid filenames and/or directories... I can find no other (easy) way to delete them

You can use the DOS del and rmdir commands to remove those things. The names aren't really illegal, they're just only understood by programs that use the NT-only file parsing, which is very few programs. (Explorer doesn't and neither does Opus.)

e.g. To create such a folder:

mkdir \\?\C:\Users\Leo\Desktop\Moo...

Since that folder has a "." at the end of its name it will confuse a lot of programs and you won't be able to delete it using Explorer/Opus's default methods.

Then to remove it:

rmdir \\?\C:\Users\Leo\Desktop\Moo...

You could create buttons in Opus which run the DOS commands on the filenames if it happens often. (Or find whatever is making them and stop it. :slight_smile:)

Is frustrating/mind boggling to me how explorer is unable to handle files/directories like these... I use compressed (zip) files that are for other non-windows systems and they sometimes have filenames that have crazy characters in them... I need to unzip and then 7z them and so they end up "stuck".

My bet is that Explorer avoids working with them because if it did in general then people would accidentally create a lot of files/folders which wouldn't work in almost everything else. That said, there's a case for saying that Explorer (and Opus) should be able to delete such files, even if they protect you from creating them.

I would put the blame on the archive tools more than anything else, though. For example, most tools that support LHA archives will blindly pass Amiga file paths to Windows API functions without attempting to map them into paths which makes sense for Windows. Sometimes it works, sometimes it doesn't work and sometimes it creates the mess we're talking about now.

Holy cow Leo you're right that was SO much easier.

It actually took me 30 minutes because I thought you were asking me to trim down my script and rewrite it.

I didn't realize that the one liner that you provided was the whole thing!

Very cool!

It is now working for folders as well. I noticed though that it doesn't work if I have the folder selected in the folder tree on the left. I have to go up one level and select the folder in the files detail pane. Is it possible to pass a directory using the folder tree?

BTW: The reason I want unlocker as a button is because windows media player does a lousy job of releasing mp3 and avi's after it's done with them. You can go on to another file and it still en queues them.

I never use it for programs that are actively running with a file. It's just for when programs do a sloppy job of closing files properly.

Thanks again.

Codes like {filepath$} work on the file display and ignore the tree.

In that situation WMP may still want to look at the file for some reason and go haywire if the handle is in an "impossible" state. (It is WMP's handle and WMP knows it hasn't closed it yet and can thus assume it isn't closed, except it is closed.)

Have you tried deleting the files within WMP? (In WMP, right-click a file and choose Delete.) I'd expect that to make it close the file and delete it. Does it work?

If not then it could be a codec issue. I've seen some codecs leak handles and it can be annoying. In that case using Unlocker is perfectly safe; the problem is there's no way to know if you're really in that situation or not. Better to close WMP (or using something else that doesn't cause/trigger the problem) to delete the files rather than use Unlocker routinely like that, I think.

It's like routinely shutting down programs using Task Manager instead of the Close button. Usually safe but asking for trouble.

Are there codes that work in the tree that do the same thing?

I usually do not have the file view open of WMP because Opus is so much more nimble and it maximizes view space on my multi monitor system.

I agree this is a codec issue. It's not ideal but it gets me where I want to go and it does not see to be having a negative effect. If I try to play the file again it just re-enqueues it.

Are there codes that work in the tree that do the same thing?[/quote]
No, not in the current version at least.

One or two of the internal commands have switches that make them work on the tree if it's active (e.g. Delete) but they are exceptions to the rule.

However, if you put commands into the right-click context menus for file types then {filepath$} etc. will work with the tree when you right-click tree items. So you could make your Unlocker command a context menu item instead of (or as well as) a toolbar button if that's any use.

Are there codes that work in the tree that do the same thing?

I usually do not have the file view open of WMP because Opus is so much more nimble and it maximizes view space on my multi monitor system.

I agree this is a codec issue. It's not ideal but it gets me where I want to go and it does not see to be having a negative effect. If I try to play the file again it just re-enqueues it.[/quote]

Oh, by the way, a tip, there seems to circulate a portable version of unlocker.

It definitely is a great utility, but to be honest, i hate installing stuff that -though very handy in case of need- I just need just once in a while.
I am always trying to find a portable version of it.

Wish same unlocking features were available within DO ...

==

[quote="donnyj"]I have to use unlocker when a directory contains invalid filenames and/or directories... I can find no other (easy) way to delete them[/quote]For such problems, I use DelInvFile. It's a freebie.

I am not sure about this. DelInvFile is now at v.3.01, but on their site they write

[i]DelinvFile was converted to a commercial version with the release of version 2.02 and is currently being marketed
as try-before-you-buy software.

As many customers were asking to be able to test the advanced functions prior to purchase, DelinvFile was converted
to Shareware with a 15 day free Trial. Note that all functions are available during the trial period.

The price for the single-user license for DelinvFile is $21.95 (USD).[/i]

=

I am not sure about this. DelInvFile is now at v.3.01, but on their site they write

[i]DelinvFile was converted to a commercial version with the release of version 2.02 and is currently being marketed
as try-before-you-buy software.

As many customers were asking to be able to test the advanced functions prior to purchase, DelinvFile was converted
to Shareware with a 15 day free Trial. Note that all functions are available during the trial period.

The price for the single-user license for DelinvFile is $21.95 (USD).[/i]

=[/quote]Oops! Sorry about that. You are right. I did not check the contents of the web site before I posted.