On 24/05/15 14:53, Ludovic Courtès wrote: > Pádraig Brady <p...@draigbrady.com> skribis: > >> On 24/05/15 12:33, Ludovic Courtès wrote: > > [...] > >>> unlinkat(4, "foo_file", 0) = 0 >>> unlinkat(AT_FDCWD, "foo", AT_REMOVEDIR) = 0 >>> unlinkat(5, "bar_file", 0) = 0 >>> unlinkat(4, "../bar", AT_REMOVEDIR) = -1 ENOENT (No such file or >>> directory) >>> --8<---------------cut here---------------end--------------->8--- >>> >>> Contrast this with the same thing on 4.0.4-gnu: >>> >>> --8<---------------cut here---------------start------------->8--- >>> unlinkat(4, "foo_file", 0) = 0 >>> unlinkat(AT_FDCWD, "foo", AT_REMOVEDIR) = 0 >>> unlinkat(5, "bar_file", 0) = 0 >>> unlinkat(4, "../bar", AT_REMOVEDIR) = 0 >>> --8<---------------cut here---------------end--------------->8--- >>> >>> So this looks like a 4.0.2 kernel bug that Gnulib’s unlinkat should >>> perhaps work around. >>> >>> Thoughts? >> >> Maybe. How widely deployed was 4.0.2 (It's not used in Red Hat land for >> example). >> How many versions was the bug present for? > > I don’t know, and I haven’t been able to find traces of a fix in that > area in the kernel. > > OTOH, after rereading the analysis at > <http://lists.gnu.org/archive/html/bug-tar/2014-08/msg00010.html>, it > may be that the 4.0.2 behavior is POSIX-conforming, in which case we’d > rather fix tar (or its tests) instead: > > The BSD behavior appears to be in line with POSIX. unlinkat() with > AT_REMOVEDIR is equivalent to rmdir(), whose specification says: > > If one or more processes have the directory open when the last > link is removed, the dot and dot-dot entries, if present, shall > be removed before rmdir() returns and no new entries may be created > in the directory, but the directory shall not be removed until > all references to the directory are closed. > > Without "..", the path resolution of the subsequent unlinkat() call > should--or at least can--fail. > > WDYT?
Yes I agree, either behavior is possible thanks, Pádraig
