On Sat, Jan 4, 2025 at 7:12 AM Tom Lane <tgl@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...
