Maybe notifications are sent slower if the event originates in another process, but I can only make wild guesses here without the Windows source code and several hours to look through it.
In my experience, it can also be down to the hardware or driver (at least with optical drivers, where some didn't send media ejection notifications at all).
I've made an edit to the manual so it's more clear, but it just means "all visible file displays in the current window".
The difference between "all" and "both" is that the folder trees get refreshed as well (something you don't usually need).
("Both" is also potentially misleading, if you think about it, since it implies two file displays when there may only be one. The manual has to walk a line between spelling out every possible permutation of effects and being readable. Similarly, "left" and "right" when talking about a dual-file display often mean "left or top" and "right or bottom", since the displays can be oriented vertically or horizontally, but being that verbose all the time makes things harder to read.)
Suggestion:
All: Refresh file display and tree (each both in a dual-display Lister).
What do you think about adding a value that makes it possible to refresh really "all" folder displays?
That makes no difference. The entry under "unspecific" is created ~ 1 second after the refresh/ejecting.
So I would need a delay command that the refresh is done after e.g. 1 second after the ejection. But when this issue is known, would it not be an idea that Opus wait in general e.g. 0,5 s or 1 s after the ejecting notification before automatic refresh (At least for the "This PC" area - I guess only there exist this issue)?
When I say I've edited the manual, I mean the master copy of it.
The web copy is updated periodically from that, and the built-in manual is (usually) updated when we release a new version. You won't see the change immediately. Please be patient.
We already have a delay, I think. Maybe your system or that particular device needs a longer delay, but there is not really any way to know how long to wait. The real issue is that the event is being generated before the state it's supposed to indicate is actually true, and that isn't something Opus is doing.
If other people report the same issue on their systems then we can take some time to look into it in more detail. For now, you might have to live with pushing F5 or just ignore it after ejecting a drive in that way. Or eject it some other way. Unless you're doing something really unusual, it seems odd to be ejecting USB sticks that often that it would be a big problem.
I tried another USB stick and there it works. No issue with unspecific device. So seems to be related to the device.
I tried also my external HDD and there is another issue: Opus does not allow to eject this device. It is listed under hard drives and not removable media. But I can eject it via Windows.
Is this a "fault" from windows?
You are right. The possible drive letters are limited.
I use now @hideifpathr:!(^(H:\\|I:\\|J:\\))
Mostly it is H:, so I could connect three removable media at the same time and the button will appear.
