Directory Opus appears to enter a tight loop when seeking to delete a large number of duplicate files. Directory Opus appears to hang, but is in fact very busy using the processor.
There are a lot of duplicate files on this device, the result of the peculiar behaviour of a file synchronisation service.
There are 547,528 files, occupying 509 GB, which have been identified as duplicates using MD5 checksum. I have successfully carried out the find step, which took a few hours, and the select step. I move on to the delete step.
This starts okay, and runs through to 100%.
This is followed by a warning that deleting files in the collection will delete the real files.
I click OK, and then receive a message box telling me that 421,336 files (totalling 404 GB) will be sent to the recycle bin. I click on delete.
I click delete.
Directory Opus then displays: preparing to delete to waste bin.
Then I get the message displayed in the image attachment.
This message does not change even if left for an hour or so. But although the screen does not change, Directory Opus is very busy. Windows task manager shows DOpus.exe taking 65 to 90% of the processor.
I have already done what I can to tidy up the external disc. Nor am I entirely sure how I can further subset the data so as to reduce the number of files that have to be examined.
Is this a known problem? Is there anything I can do to help to resolve it?
It's either the deletion itself that's using the CPU time, or tracking the changes made by the deletion and updating the window and/or the Duplicate Files collection.
To things, start the deletion/recycling, and then close the lister window (and any other listers that are open), so just the progress dialog is left.
If the CPU usage is still high, open a lister, go to the main Collections folder ( coll:// ) and delete the Duplicate Files collection (and any others you have and no longer need) so that changes to the files it points to no longer need to be tracked.
Another thing to try: Turn off Preferences / File Operations / Deleting Files / Delete to Recycle Bin where possible (supports undo) and repeat the process.
(Of course, this will delete the files outright and you won't be able to restore them, so be careful.)
If only deletion via the recycle bin is slow then the issue is probably outside of our control, and a problem with the Windows Recycle Bin API, which I doubt Microsoft designed for accept a list of half a million individual files in an efficient way. (It can efficiently delete folders which contain that many files, but that's not what's happening here; it has to be given a list of each individual file.)
A brief progress report, to thank you for your very swift response to my enquiry.
I decided to start off by following the suggestion of deleting the active lister window. I've tried this a couple times. Both times, shortly after deleting the lister window, the delete process also drops out.
I do have a complete security copy of the (very large) folder which I am seeking to tidy up, so I shall I go on to try Preferences / File Operations / Deleting Files / Delete to Recycle Bin.
I am mildly disturbed by the fact that there are no messages at all, which might be consistent with a genuine programming "error" which gives rise to a genuine loop. (I have put "error" in quotation marks, because I fully accept that what I'm trying to do is at least unusual. Programmers should assume the unusual; I doubt that they should have to take into account the frankly bizarre!)
I doubt it is an infinite loop. It's probably just taking a very long time because the recycle bin was designed to delete a small selection, not a huge list. So no error, just inefficiency, which may be in Windows or Opus at this stage.
