Page 1 of 1

Why Does XplorerPro Prevent USB drives from Ejecting?

Posted: 2010 May 15, 00:57
by soonerlater
I've noticed that if I have an Xplorer2 Professional (1.8.0.1) window open to a USB drive that I cannot eject the drive using the "Safely Remove Hardware" which is built into the Windows XP operating system and usually found in the systray reprsented by an icon with a green arrow pointing left and down -- no matter how long I wait. However, if I have a regular Windows Explorer session open to a USB drive and try to eject it, Windows will allow me (if all writes to the drive have been completed) to eject it. The drive which represents the USB drive just disappears gracefully from Windows Explorer. Windows Explorer doesn't keep the USB drive open or fail to adapt when the USB drive is no longer 'hot."

Why doesn't Xplorer2 Pro do this?

===============================================
* Note: if your "Safely Remove Hardware" icon disappears, you can restart it by running this command:
 RunDll32.exe shell32.dll,Control_RunDLL hotplug.dll
or you can run one of the various aftermarket USB management apps/applets, such as USBDeview (free at www.nirsoft.net) or USB Safely Remove ($20.00 at www.safelyremove.com).[/u]

Posted: 2010 May 15, 06:22
by nikos
first browse away from the USB stick eg switch to the other pane, then eject will work

Posted: 2010 May 18, 19:08
by rsleegers
This does work to release the lock, however if I have a dual pane open, then browse to the USB device using a single pane viewer (the installers' integration option was enabled) and then close the pane, the USB stays locked. If I re-open the single view window, create another pane and switch to it I can then eject.
I would expect that closing a window would be the same as switching to another tab or to another instance of xplorer2. Switching between tabs of the previously opened dual pane window does not release the lock. Don't lock browsed folder is checked. My version is 1.8.0.11.

Posted: 2010 May 19, 04:10
by ckit
I orginally purchased a copy of "USB Safely Remove" to fix this problem, now days I only use Windows Explorer's Libraries shortcut on taskbar for handling USB drives too.

Posted: 2010 May 19, 04:40
by nikos
the option 'don't lock browsed folder' could be a bigger PITA if you start something from the USB. In that case you must start something (d-click on something) on a different folder to release the lock

Posted: 2010 May 26, 14:11
by teknowledgist
What I find frustrating is when I close the Xplorer2 window displaying the contents of a USB drive, and then at some later time (hours) when I want to eject the drive, I can't because it's "in use".  

First, I have to check that it's not some application with an open document.

Sometimes I can open Xplorer2, view the USB drive, switch to another drive, close Xplorer and then safely eject.

Too often, I have to close all Xplorer2 windows, open Task Manager, and kill the Xplorer2 process (why is it running with no windows open?) before I can eject my USB drive.

Is my computer screwed up, or is this "expected"?  

Thanks.

Posted: 2010 Jun 05, 09:22
by Hermanito
My experience with this issue is as follows:
Try to avoid selecting the USB-stick from the treeview, because if you then browse away from the USB-stick in the filepane, its driveletter is still selected in the treeview (supposing you don't use the autosync option for the tree) and this also blocks ejecting the stick.
Using the driveletter-toolbar does not have this problem.

A workaround is to first select another drive in the treeview when browsing away from the USB-stick contents...

Posted: 2010 Jun 06, 09:05
by Cosmo
Often enough I came across the same problem and all the workarounds (not to forget: a workaround is no professional solution :!: ) did not do it reliable.

I found the following approach working: I open a new tab before I display the thumb drive. After closing this tab (ctrl-f4) I can eject the drive. But this is really frustrating, if I forget to open the new tab beforehand. (I don't know if this technically correct, but it appears, as if the tab's history is to blame for the problem.)