Since updating to version 13 I get an error when deleting a folder with a large amount of files within in (~700-1000 files). I hit the delete button and a dialog comes up confirming the action. It lists the correct amout of data within the folder but then proceeds to only delete ~400 files and throws an error that the folder is not empty. Doing the action again just lists the files it did not delete and confiming then deletes the folder. Not 100% sure if its cause by just the number of files or whether folder size also plays a part. These folder are located within a network share via SMB as well so that might be related. Next time I do this I will copy the folder locally and test that.
EDIT: just happened to find a folder to test with and the error does not occur when folder is located locally so only occurs when working on network share. Deleting using windows file explorer when the folder is located on the network share also works fine which suggests an issue with directory opus.
Are you deleting to the recycle bin when this happens?
Could you show a scteenshot of the confirmation dialog? That should show how the delete is happening.
What kind of network drive is it?
Are you selecting the parent folders and files all in one place, or are they in multiple places, via Expanded Folders, Flat View or a (Find Results) Collection?
Has the Delete Filter been turned on? (Look in the menu attached to the toolbar Delete button to find out.)
I'll take a screenshot next time I remove a large folder.
Being a network drive nothing gets moved to the recycle bin, all dialogs are for permanant delete and display "this operation cannot be undone".
Its a SMB share via the "\COMPUTERNAME\SHARE" path hosted on a local unraid storage setup. I will test mapping the drive in windows next time to see if that solves it.
I'm just selecting the parent folder in a standard directory opus tab. I did earlier test opening the folder first and selecting all the files and they all deleted fine. Seems to only occur when trying to do it via the parent folder.
The delete filter is turned off, don't think this is something I have used before.
Next time it happens, check if there is actually anything still in/below the folder (make sure hidden files are being shown etc. too). The file/folder that's still there might reveal something.
I'd also check if waiting a few seconds and clicking Retry works. If so, something may have had a file open (but allowing deletion) that was deleted and remains there until the thing that had it open closes it, which in turn prevents the parent directory from being deleted.
I have done some more testing and wrote a script to create 1000 small txt files to test with and it turns out this appears to be a bug in Unraid and I don't think its an issue with directory opus.
It threw me off a little as the issue only occurs in Directory Opus and not windows explorer but further testing says its a server side issue on the SMB share. I wonder if Directory Opus uses a different version of smb or some additional settings that is triggering it
Ether way I don't believe the issue lies with Directoy Opus, thanks for getting back to me quickly
Opus either calls the Recycle Bin API or the DeleteFile API, depending on how the delete is done.
Both are high-level APIs that just take some file paths and flags and then the operating system does the rest. Opus has no knowledge (or care) about different SMB versions, and never talks SMB directly -- the operating system does that -- so it won't come down to that.