Repository navigation
rm doesn't really traverse directories like GNU rm at all, will fail on deeply-nested paths #2949
Description
GNU rm avoids constructing path strings of unbounded length to allow recursively deleting directories whose absolute paths exceed the max path length a Linux syscall can take. For more information please refer to this blogpost I wrote a while ago: https://unterwaditzer.net/2021/linux-paths.html
The rm in this repo appears to construct Path objects and therefore almost certainly will fail to remove the nested directories constructed in that article.
IIRC BSD rm works similarly to GNU rm here, and I would not be surprised if POSIX mandates a solution that works on really deeply nested filepaths.
There's probably more utilities in this repo which use Path objects, which immediately makes them fail in those edgecase situations where the equivalent GNU version might not.
Activity
tertsdiepraam commentedon Jan 29, 2022
Interesting! So, if I understand correctly GNU does a sort of depth-first-traversal of the directories, removing each one it steps out of? We're currently traversing the directories with
WalkDir. They have an open issue for this too, with some interesting discussion.untitaker commentedon Jan 29, 2022
that's exactly the issue. i attempted to implement directory traversal with openat here: https://github.com/untitaker/fdwalk
it will depend on usecase whether that's feasible. for ripgrep i believe it doesn't make any sense, as it needs to print filepaths, keep track of globs, ignorefiles, etc. for something "simple" and "essential" like coreutils i think it's necessary (it would suck if the OS gave me no tools to delete certain directories, so a "coreutils" command should always choose reliability over speed imo). it's also not too hard to do it as long as you don't use verbose option.
tavianator commentedon Apr 4, 2022
Indeed, https://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html says:
stale commentedon Apr 4, 2025
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
untitaker commentedon Apr 4, 2025
valpackett commentedon Sep 17, 2025
Please consider cap-std for working with nested paths.
untitaker commentedon Sep 17, 2025
this issue might actually be fixed by #8517
if you want to recursively delete a directory, you will eventually want to run
openat(X, "../")to exit the recursion, and then delete that directory. from what i understand cap-std is designed to prevent this. keeping the parent file descriptor open will cause another pathological case where you run out of file descriptors in deeply-nested directoriesthe8472 commentedon Sep 17, 2025
Note that you have to be extremely careful around this, otherwise you expose yourself confused deputy attacks.
See the discussion in rust-lang/rust#93160 (comment)
rm: fix segfault on very deeply nested directories
rm: fix segfault on very deeply nested directories
rm: fix segfault on very deeply nested directories
rm: fix segfault on very deeply nested directories
rm: fix segfault on very deeply nested directories
rm: fix segfault on very deeply nested directories
rm: fix segfault on very deeply nested directories (#14554)
rm: fix segfault on very deeply nested directories (uutils#14554)