Closed hhyyrylainen closed 8 months ago
Hello @hhyyrylainen
I believe this bug has been fixed by 114c84bf40dca06c1bd257517d583fa9d9ab7f95 and bbc22672bef3c6a3739a4c3158ab7a069d372955
Files that could not be scanned for some reasons (like yours, which were deleted) used to create an infinite loop as you described
So this should be fixed in version 0.13? That's great to hear. I see Fedora 38 is not going to get the update (https://bodhi.fedoraproject.org/updates/FEDORA-2023-16541f0464), but I should get the latest version then once 39 comes out soon. In the meantime I'll hold off on adding a cron job to run duperemove so that I can manually keep an eye on if things get stuck.
Sorry if this has already been fixed in the latest version but using version
duperemove 0.12
I noticed that if I don't give the-d
flag then after the file hashes are calculated it seems the same duplicates / no duplicates are detected in an infinite loop and duperemove never exits without me hitting CTRL-CThen those last 3 lines repeat infinitely. I may have caused an issue by pre-emptively noticing things in the duplicate output that I definitely didn't need and deleted them. On a previous run I noticed that the tool output a bunch of duplicates which it then repeatedly re-printed after a minute or so. So I'm opening this issue as I didn't find an existing one about this tool getting into an infinite loop at the end. I have one more big initial check running without
-d
, I'll report back here when that finishes whether that gets into an infinite loop or not.Update: that other duperemove run I had on a disk where I didn't delete things completed just fine after printing the duplicates found just once.