I found a helpful context menu that I didn't know was there before, for a removable USB stick:
Eject? Ok good, now I don't have to use the Windows 10 taskbar to eject.
(Using command lines with a Dopus button doesn't work, as the drives seem to have variable, not static drive letters, depending on the chronological order they were plugged in; I'm not sure)
But I got an error message that something is using it, but nothing was using it:
I get the feeling Dopus was "using it" as it has that issue with other things.
This is an important USB stick, so I have to be careful of corrupting it. How come Dopus is locking the drive from ejection?
Especially when I have it set to 'Quick Removal'. ? (I just learned about quick removal)
Can I be confident removing USB drives without ejecting them when Dopus is running?
It could be Opus using it or it could be something else entirely. You have a “feeling” Opus is doing it but haven’t tested that, so the question is very hypothetical.
It could also be a shell extension something else has installed that runs inside Opus but isn’t Opus.
I get the feeling because I didn't design this software. But you did, so I'm here asking the person who did. I don't even know if a file manager could or would lock a usb drive, or if that's even a thing. All I know is that I'm getting these pop ups.
It's possible it's my password manager keeping the usb drive locked, because I used a file on it as a password key. But that doesn't make sense, since it only needed to read the file one time and that's the end of that relationship.
Anything that accesses the filesystem could lock a drive. It might be Opus, but it might also be other things.
It could well be that.
For example, the standard File Open dialogs in Windows may (depending on how they are used) set the folder you select a file from as the processes's current directory. If a process has its current directory set to a removable drive, the drive cannot be ejected until the process changes to another directory or exits.
Or if a process has a file open on a drive (and doesn't just open it, read it all into memory and close it), that will also prevent the drive from being ejected.
I didn't think to test it without the password manager involved.
The drive does eject with Dopus running. Even when it has its folders open in a Dopus lister.
When I use the Windows "safe eject" (from the taskbar) the Dopus lister closes out the drive from Dopus no problem.
So what I'm going to do is rely on the Window's 'Quick Remove' feature. To avoid the extra step in manually ejecting it first, before unplugging it. Keeping another usb backup as a safety net; usb sticks are cheap. And rethinking my password manager login method. Thanks for the help.
What command is generating the "fixed drives" toolbar list?
Does the list include the drive in question? (It'd be unusual for it to have an "eject" option if it's also reporting itself a s "fixed" i.e. non-removable drive.)
It doesn't have an eject option. I've been using the windows taskbar to eject.
If you recall, I had made a button to eject (with that nirsoft command line), but got rid of the button; the drive letters seem to choose either E or D, trading the name with each other depending on what's plugged in at the time. I bet that if I looked I can find a way to lock them to a drive letter, and then I can create new eject options for them in Dopus, but haven't yet.
I had two buttons before: fixed and removable. I first got rid of the removable one and oddly the plugged in usb drive was still appearing on the toolbar. So I got rid of the fixed one. Then I was able to eject. When looking for the command to replace them, I couldn't find those old ones, I only found my now current one, which has any type of drive, from the looks of it. The first pic I posted here shows my new one, and that one is these pics below:
So with the older or new buttons they sometimes refuse to allow usb eject. Maybe it's because Dopus is displaying their existence on the button itself.
The source of my usb locked issues might be the Everything Search Tool.
I recently learned that it indexes removable drives if you don't tell it not to.
I checked and I haven't yet explicitly disallowed the indexing of my usb drives. So now I did and then ran some tests and even with the Dopus drive buttons on my lister and Dopus running I'm able to eject them without any errors.
If I have recently used the usb drive(in my case media cards like XQD,MicroSD, and SD using eject in the context menu in Directory Opus or from window 10 taskbar "safely remove hardware", i get the 'in use' pop up. I always make sure the files or media are not highlighted in the viewer pane and i always click too another drive so that it is not 'active'.
Even when I do that I still get the 'in use' popup. clicking try again over and over does not work.
What does work is terminating Directory Opus. If I close out the program via taskbar conext menu and quit, I can immediately eject the 'in use' cards. Closing the DO window does not work I have to fully kill the program.
Any more info or thoughts on what might cause this as I'd prefer not to have to quit the app every time I want to eject a drive.
If the drive is still in use a minute or two after closing all windows, and exiting the program fixes it, it's often due to shell extensions or video demuxers/codecs which failed to release a file or got stuck while processing it.
Those aren't part of Opus itself, but do run inside of our process, so if they lock something in our process and fail to unlock it, it'll stay locked until the process ends.
It could also be a bug in our code, but that would be more likely to affect more people all the time (unless it's triggered by something unusual).
Working out the type of files or actions that result in a lock is a good way to narrow it down to a particular component.
I think you are right about some lingering codec/extnesion hook. It seems like after 2-3mins of not using the disk, I am able to eject from DO context menu properly.
Using the context menu, from the taskbar icon, to exit program always working immediately, so I can continue doing that.
Due to the constant rate at which I insert and eject disks like this for my work, it's definitely helpful to not have to terminate DO just to continue working. Hence my initial post here.
I may upgrade to DO 13 at some point so if that's an issue there I will report back.
Thanks this is helpful. I may set up a hotkey for exiting program.
That said the whole issue is having to take extra steps of closing and reopening the program, costing me time over a continuing duration of work hours/days/weeks. Not terrible but not ideal!
A while back Microsoft added an option to not need to eject usb devices before unplugging them. It cache's the changes or something so that when you unplug a device it doesn't get corrupted. I don't know the details but that might be something you would want, since you unplug devices so often.
Thanks but I corrupted a USB drive recently doing that and cooked some work stuff. This was directly after getting frustrated by the 'item in use' pop up that is being discussed in this thread. No way I take that chance again.
I'm also on Win 10 if that makes a difference.
Do you have any source for that?
For me, this is the exact origin for the need to unplug properly: some actions are cached by the os, so when you think the operation is done (for example some copy with modified files), in reality some actions are still in progress at the lower level of the drive. And if you unplug at that moment, data on the drive gets corrupted.
Note that some filesystem do not comply with that.
NTFS does, but AFAIK FAT and extFAT do not (so they can be unplugged safely).
95% of all "files are corrupted on a removable drive" problems are caused by "just unplugging". Writing to these drives would be really really slow would it not involved caching data and lying to the user that the data has been written. While you can turn off SOME of this write caching in OSes, there still will be a window of time where data really has not been fully written to the storage area of the device - especially as large capacity drives of course have their own internal caching mechanisms and unplugging them might stop their internal caching.
No matter what your OS tells you. Always, always, ALWAYS "eject" USB devices before unplugging.
And yes, if Windows says "I can't eject right now", any rogue process might have forgotten to tell Windows that it does not need write access to the drive anymore. Next to impossible to debug, Microsoft PowerToys have a tool to find file locks, but only on a file level. Have not seen a tool (yet) that checks if ANY file on a drive is still open by ANY process (and then tells you that process).
It's not only Windows, by the way. I keep helping people using Linux distributions for Retro Game Emulation with large collections on TB-level SD cards who lose their collections because they just pull out the SD card when there still were uncached writes.
