Hi all! Not sure whether this is a bug in the software (12.27 pro). If not, I want to create a feature request.
TL;DR: "Don't prompt confirmation if deleting to Recycle bin" (translated, maybe another text in English version) parameter works incorrectly.
The default settings in Opus make it to delete files via Recycle bin and don't prompt a confirmation message (just like in Windows Explorer). This works fine.
However, when you delete any files on a drive that does not have a recycle bin (for example, drive mapped by Cryptomator via WinFsp) - file gets deleted directly and no warning is shown. Windows Explorer shows confirmation message in this situation, and I think there should be atleast a separate parameter in the Opus settings for this as well (if not always-on confirmation).
I can't reproduce what you describe using a network drive as the test.
With both options ON:
Ask for confirmation before commencing delete
Skip confirmation when deleting to Recycle Bin
If I select a file on a network drive and push Delete, Opus asks me for confirmation.
(If I do the same with a file on a local drive, it goes into the recycle bin without prompting.)
Do you see this on all drives without recycle bin support, or does it only affect Cryptomator/WinFsp drives? I'm not familiar with that product, but I suspect it's doing something which makes it appear to Opus like it supports the recycle bin when it doesn't.
currently I've only tested with Crypto/WinFsp. for the OS those mapped drives are just normal local drives, not network drives. maybe that's why DOpus misunderstands them, not sure. on the other side Windows Explorer handles them correctly so I think the issue is with DOpus, not WinFsp.
also (I think it's obvious now but anyways) want to say that Undo feature logs those deletes but fails to restore them.
When we tell Windows to delete the files, we explicitly tell it to show a warning if the operation cannot be undone. This is ALWAYS set for any Delete which goes via the recycle bin API, no matter what you choose in Preferences.
When we call the Recycle Bin API, we specify FOF_WANTNUKEWARNING, which is documented as:
Send a warning if a file is being permanently destroyed during a delete operation rather than recycled. This flag partially overrides FOF_NOCONFIRMATION .
So this is either a bug in Windows or a bug in the encryption software, as the flag we set is not being respected.
A similar issue came up with BoxCryptor a few years ago, where different mounting options within BoxCryptor were found to be a workaround:
well I won't be shocked if that's really a bug in Windows that Explorer bypasses by itself.
thanks for clarification, the only option left is to use warnings for every deletion now.
I've tried to additionally debug that situation and found out:
Directory Opus calls SHFileOperation with the following flags: FOF_ALLOWUNDO | FOF_NOCONFIRMATION | FOF_NO_CONNECTED_ELEMENTS | FOF_WANTNUKEWARNING (logged using API Monitor)
Explorer doesn't call it at all, probably uses IFileOperation (MSDN says it's the preferred way for Vista+)
I've tried to replicate the behaviour and built a simple console app to call SHFileOperation and found out that FOF_NOCONFIRMATION flag seems to be the reason (FOF_WANTNUKEWARNING doesn't "partially override" it as MSDN says, maybe a bug indeed or incorrect documentation).
So when I call:
fileOpStruct.fFlags = FOF_ALLOWUNDO | FOF_NOCONFIRMATION | FOF_NO_CONNECTED_ELEMENTS | FOF_WANTNUKEWARNING;
Result:
-When removing file from a regular drive, uses Recycle Bin, produces no confirmation (OK).
-When removing file from a virtual mapped drive, does not use Recycle Bin, produces no confirmation (BAD).
fileOpStruct.fFlags = FOF_ALLOWUNDO /* | FOF_NOCONFIRMATION */ | FOF_NO_CONNECTED_ELEMENTS | FOF_WANTNUKEWARNING;
Result:
-When removing file from a regular drive, uses Recycle Bin, produces no confirmation (not as documented but OK for current situation).
-When removing file from a virtual mapped drive, does not use Recycle Bin, produces confirmation (OK).
So maybe FOF_NOCONFIRMATION is useless and even dangerous on modern Windows?
Update1: Actually FOF_WANTNUKEWARNING is not needed too now for producing a confirmation.
But yeah I've only tested on my specific drive so maybe it's still relevant for other types of drives.
The default configuration in Windows has delete confirmations turned off, which might appear to make the flag which suppresses them do nothing, but it may still do something when they’re switched back on.
(Makes me wonder if Microsoft broke the API when they changed the default settings. They rarely seem to test things with non-default settings these days. The Start Menu breaks if you toggle the setting for sending mousewheel scrolling to the active window, for example.)
can you, as a (maybe temporary) workaround, detect that confirmation is disabled at OS level and do not provide that flag in a call as unneeded?
moreover, what do you think about when user explicitly enables delete confirmation at OS level, should DOpus use it's own confirmation dialog instead of built-in one?
I'm not sure if there is a (documented/supported) way to find the setting. While it may explain why FOF_NOCONFIRMATION didn't seem to do anything in your tests, we'd still need things to work with Windows delete confirmations both on and off, too.
Some other avenues:
SHQueryRecycleBinW may be able to detect whether or not the recycle bin is supported by the drive. It should return E_FAIL (0x80004005) if the drive doesn't support the recycle bin.
When using IFileOperation, the caller can provide an IFileOperationProgressSink, where IFileOperationProgressSink::PreDeleteItem should be called before any file is deleted outright (instead of going to the recycle bin). That may be a place where we could add a confirmation/cancel prompt.
I was thinking about making a test app for you so you could try it on the drive (since I don't have it set up here to test against), but if you're a programmer and already comfortable with Windows API stuff then it might be simple to do yourself.
ERROR_UNRECOGNIZED_VOLUME
1005 (0x3ED)
The volume does not contain a recognized file system. Please make sure that all required file system drivers are loaded and that the volume is not corrupted.
I believe that's just a strict check against known FS names, pretty stupid actually since FUSE fs seems to support Recycle bin if enabled in registry.
IFileOperationProgressSink::PreDeleteItem is indeed called, either without OS confirmation or after it's approved (if once again I don't provide FOF_NOCONFIRMATION flag, as it breaks IFileOperation call as well).
Thanks for trying those with the drive! So it seems the end result is the same as doing things the other way. The API seems to be broken, at least when combined with this drive/filesystem.