I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
Have you tried finding all the symlinks (try find .Trash-1003 -type l in the first instance) and deleting them individually?
I suspect that rm is following the links down to delete the nodes first, then backing up the tree. If a symlink is pointing to itself, its parent, or another symlink which is pointing, in turn, to one of those, then rm will recurse forever.
Running findwithout the -L option should mean it doesn't try to recurse within linked directories, so it shouldn't get the same problem as rm.
There're probably just one or two problem links and using rm on them one a time should work.
.Trash-1003
.Trash-1003/files
.Trash-1003/files/.git
.Trash-1003/files/.git/objects
.Trash-1003/files/.git/objects/8f
.Trash-1003/files/.git/objects/8f/*
find: ‘.Trash-1003/files/.git/objects/8f/*/*’: Too many levels of symbolic links
.Trash-1003/files/.git/objects/8f/*/.. (
find: ‘.Trash-1003/files/.git/objects/8f/*/.. (/8f’: Too many levels of symbolic links
.Trash-1003/files/.git/objects/8f/.. (
find: ‘.Trash-1003/files/.git/objects/8f/.. (/8f’: Too many levels of symbolic links
It looks like it's the */ and (/, but deleting those just throws that same error.
surprised you didn't suggest -exec rm -rf {} \; as an addon to the find....
Though, in the case of unusual issues, I tend to prefer going a bit deeper than most people, why not use the inode reference and delete it specifically by inode, though in this particular case, that should be drastically overkill.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
I didn't suggest that because I don't see how it'd be any better than the original attempt - we've already established that rm -rf doesn't work if the directory contains some kind of self-reference. I'm not sure why the find came out with that output though, because it looks like it's reporting a lot of things that shouldn't be links.
I don't really know though, I'm just guessing.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Have you tried finding all the symlinks (try
find .Trash-1003 -type lin the first instance) and deleting them individually?I suspect that
rmis following the links down to delete the nodes first, then backing up the tree. If a symlink is pointing to itself, its parent, or another symlink which is pointing, in turn, to one of those, thenrmwill recurse forever.Running
findwithout the-Loption should mean it doesn't try to recurse within linked directories, so it shouldn't get the same problem asrm.There're probably just one or two problem links and using
rmon them one a time should work.Your solution might've worked too, but I didn't test it when I moved it off the external usb.
It looks like it's the
*/and(/, but deleting those just throws that same error.surprised you didn't suggest -exec rm -rf {} \; as an addon to the find....
Though, in the case of unusual issues, I tend to prefer going a bit deeper than most people, why not use the inode reference and delete it specifically by inode, though in this particular case, that should be drastically overkill.
rm -rf ./.git should be sufficient.
I didn't suggest that because I don't see how it'd be any better than the original attempt - we've already established that
rm -rfdoesn't work if the directory contains some kind of self-reference. I'm not sure why thefindcame out with that output though, because it looks like it's reporting a lot of things that shouldn't be links.I don't really know though, I'm just guessing.