Repository navigation
rm doesn't really traverse directories like GNU rm at all, will fail on deeply-nested paths #2949
Description
Activity
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.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.
Reacted by Scott Olson and Iacopo MolesI would not be surprised if POSIX mandates a solution that works on really deeply nested filepaths.
Indeed, https://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html says:
The rm utility shall be able to descend to arbitrary depths in a file hierarchy, and shall not fail due to path length limitations (unless an operand specified by the user exceeds system limitations).
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.
- this is still an issue.…On Fri, Apr 4, 2025, at 05:36, stale[bot] wrote: 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. — Reply to this email directly, view it on GitHub <#2949 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMPROELA5HYHFTOLP4W532XX44FAVCNFSM6AAAAAB2NW2EK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZXGQ4DCNBZGU>. You are receiving this because you authored the thread.Message ID: ***@***.***> stale[bot]*stale[bot]* left a comment (uutils/coreutils#2949) <#2949 (comment)> 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. — Reply to this email directly, view it on GitHub <#2949 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMPROELA5HYHFTOLP4W532XX44FAVCNFSM6AAAAAB2NW2EK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZXGQ4DCNBZGU>. You are receiving this because you authored the thread.Message ID: ***@***.***>
Please consider cap-std for working with nested paths.
this issue might actually be fixed by #8517
Please consider cap-std for working with nested paths.
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 directoriesopenat(X, "../")
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)- added 7 commits that reference this issue
on Sep 14, 2026 - added a commit that references this issue
on Sep 28, 2026 - added a commit that references this issue
on Oct 7, 2026
GNU
rmavoids 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.htmlThe
rmin this repo appears to constructPathobjects and therefore almost certainly will fail to remove the nested directories constructed in that article.IIRC BSD
rmworks similarly to GNUrmhere, 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
Pathobjects, which immediately makes them fail in those edgecase situations where the equivalent GNU version might not.