On Sat, Jan 4, 2025 at 7:12 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > One thing I noticed while testing yesterday is that "rm -rf foo" > worked even in cases where "rmtree foo" didn't. I did not look > into FreeBSD's rm code, but I'll bet it has the sort of retry > logic that was recommended to us upthread.
It punts the directory scan to the fts_read() etc functions (directory traversal helpers widely inherited from ancestral BSD but not in any standard), which buffers the scan and probably hides this issue: https://github.com/freebsd/freebsd-src/blob/main/bin/rm/rm.c https://github.com/freebsd/freebsd-src/blob/main/lib/libc/gen/fts.c I doubt that hides all potential problems though, if I have understood the vague outline of this bug correctly: perhaps if you ran large enough rm -r, and you unlinked a file concurrently with that loop, you could break it, that is, cause it to skip innocent files other than the one you unlinked? glibc also has an implementation of the BSD fts functions, and uses them in its rm: https://github.com/coreutils/coreutils/blob/master/src/rm.c https://github.com/coreutils/coreutils/blob/master/src/remove.c > As for pre-existing bug reports, I found > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=57696 > > but there's basically no new information there, other than > the not-so-surprising fact that renaming directory entries > triggers the failure as efficiently as unlinking does. FWIW I am discussing this off-list with Rick, I *think* we can distinguish between "gripes abouts NFS that we can't do much about" and "extra thing going wrong here". The fog of superstition around NFS is thick because so many investigations end at a vendor boundary/black box, but here we can understand the cookie scheme and trace through all the layers here...
