Date: Sat, 04 Oct 2014 20:56:59 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 192490] [build] race condition with multiple instances of cleandir in subdirectories; results in failure like "rm: fts_read: No such file or directory" Message-ID: <bug-192490-29464-2ntjgoMTAf@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-192490-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-192490-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192490 --- Comment #10 from Warner Losh <imp@FreeBSD.org> --- Ian: the problem is that directory foo has a subdir bar. So running rm -rf in both foo and foo/bar (especially when there are several bars) is what causes the issue. rm was too stupid to not generate an error when it was trying to read an entry that went away by some other agent. bde thinks this is a standards violation, but I'm not convinced by his reasoning. Adding actual debugging to rm shows that running in both is the issue, and it fails to properly ignore the ENOENT it gets when reading the subdir.. This is caused, I think, by not waiting for all subdirs to finish in clean targets before doing the current directory. Or maybe the -Rf in the first place is the bug that's masking this not waiting. I believe the -rf in question is in bsd.obj.mk where it deletes the CANONICALOBJDIR since CLEANDIRS isn't used in the sys/modules tree. It would appear that the for loop in bsd.subdir.mk that has the ${__target}: ${__subdir_targets} dependency isn't strong enough to force the recursion to finish before the current target is run. That might be a fruitful line to try to investigate. If you fix that, then the -r likely can go away if you think about it (though we'd need to add a seperate rmdir to get the same effect, which would have the added benefit of catching when the directory isn't empty due to missing CLEANFILES, since our build system has opted for the "you must list everything" approach elsewhere the -rf is a bit of a outliner in the current system). So by all means, look at the build system, but it is my belief that the fix in rm is actually standards-ly correct and fixes this bug. A build-system fix would help those systems with rm that isn't quite standards compliant. -- You are receiving this mail because: You are on the CC list for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-192490-29464-2ntjgoMTAf>