Hello,
For quite a while now, when I try and Shift+Delete any folder, I get the "Folder is not empty 145" error.
I've run chkdsk and I can delete the exact same folder/s in File Explorer or other software without issue.
I've rebooted and updated, nothing seems to fix it.
Edit: I'm using the latest stable version - 12.24
Does waiting a moment and clicking Retry also work, or do you keep seeing the same error?
Is the folder actually empty, or are there still things left in it? (Check for hidden/system files as well. If using Opus, you can click the hidden count on the status bar to disable all filtering and show everything.)
(A file delete can succeed but leave the file still there in a "pending delete" state until something else which has the file open closes it. It's rare but would be a legitimate cause of that error message. Happens most often with video files, in my experience, due to the way some video components open them. You should still see the file in the directory in that case, though.)
From a quick search, it seems to be a problem a few people have run into on Windows 10 with various tools (most part of the OS itself), but isn't something I've heard about before: windows - How to solve "The directory is not empty" error when running rmdir command in a batch script? - Stack Overflow
If it only happens on a NAS then it could be the NAS doing something unusual on its side, but if it also happens on local drives and the folders really are empty then it's unexpected. Antivirus or similar tools could be involved, perhaps, as they can modify the way the filesystem APIs behave.
A Process Monitor log of what happens might reveal some more details.
Retry just shows the error again immediately, only way out is to abort.
The folder isn't empty, but I shouldn't need to go through the delete every file and folder by hand should I? I don't have to with File Explorer.
I've tried it on newly created, but unopened folders.
I've also tried it on folders I've not accessed for months or years.
This isn't a NAS, this is my local machine, albeit, not on my main hard drive.
The strange thing is, only Directory Opus has this issue. I can get the error, then immediately try deleting the exact same folder in File Explorer and no issues, the folder gets deleted.
Also, this doesn't just happen with the odd folder, this happens for all folders. But just tested, on my main drive (SSD) where Windows is installed, I don't get an error, it is only on my 2nd drive (HDD).
You shouldn't need to. But that's an important detail. It means the contents aren't being deleted for some reason.
Check that the Delete Filter is not turned on, as that could cause things to be skipped:
Does it make a difference if you delete with the Recycle Bin or without it?
Is the second drive formatted as NTFS or a different filesystem?
What types of files are being left in the folder?
Delete Filter isn't on.
When I delete without pressing Shift, it works fine, and the folder is deleted/moved to the recycle bin.
All my drives are NTFS by the looks of it.
This particular folder I'm testing, nothing is deleted at all, so all folder and files remain.
That is the folder chain I'm trying to remove. I'm trying to delete the "bin" folder.
If you make a folder on the same drive with just some .txt and .jpg files in, does it have the same problem?
A bin folder might have things inside which antivirus is still scanning, perhaps. Using the Recycle Bin may also be avoiding the problem as it really just moves the files rather than deleting them.
What does Shift + Delete in File Explorer do?
I used File Explorer to create a new folder at the same level as the bin folder, and added an image, a blank text file and a blank excel file, then went and shift+deleted it in DOPUS and it deleted fine, no errors.
I then created the following folder structure:
folder
|> image file
|> folder
|>> image file
|>> folder
|>>> image file
|>>> folder
|>>> folder
|>>>> image file
And when trying to shift+delete this, it gave me the 145 error.
So it seems to only have a problem if the folder contains subfolders? Or subfolders with files in them?
When I shift delete in the following applications, I get no errors, it just deletes the folder structures:
Please make some Process Monitor logs and we'll see what they reveal.
The logs show that the bin\Debug directory on that drive was flagged as reparse point. That usually means it's a junction or symbolic link or mount point or similar, but can (rarely) have other meanings.
If a directory is flagged as a reparse point, Opus won't try to delete the things under it, on the assumption they're likely to be part of another directory which the thing being removed is only pointing to and not the real owner of. The aim is to remove the junction/link but not delete the things it pointed to somewhere else.
The question is why it's flagged in that way. Is there anything unusual about it? Is it actually a link to something else? Or are any tools being used that do unusual things with the filesystem (e.g. blocking access to folders)? Cloud storage or sync tools affecting the folder or its parents? If we can understand what the directory is then we may be able to check for the situation.
Ahhh, a sync client.
My entire Dev directory is set up to be synced using Synology Drive Client, so all my stuff is backed up automatically to my NAS.
Could this be the issue?
Actually, I just tested this on the same drive outside of that folder with the weird test folder structure I used above and DOPUS deleted it fine.
This is annoying, I'd rather not have to stop syncing that drive to my NAS. Are there any workarounds?
That explains it, and was a bug on our side, which I've just fixed.
The fix will be in the next beta.
While testing, I found the same problem happens with OneDrive folders. (It's surprising this wasn't seen/reported before now. I guess most people who use OneDrive also use the recycle bin.)
The best workaround for the time being is to use the recycle bin, if possible, since that shouldn't be affected by the issue.
Oh nice. Glad I pointed it out, I've been ignoring it for months lol and it's lucky I live inside my dev folder!
Thanks for helping me, great support!
Thank you for the report and all the useful info!
