Bruno Haible wrote:
> Hi Jim, Eric,
>
> On MacOS X 10.5, the unlink() and unlinkat() tests fail:
>
> test-unlink.h:49: assertion failed
> /bin/sh: line 1: 17670 Abort trap EXEEXT='' srcdir='.'
> ${dir}$tst
> FAIL: test-unlink
>
> test-unlink.h:49: assertion failed
> /bin/sh: line 1: 63034 Abort trap EXEEXT='' srcdir='.'
> ${dir}$tst
> FAIL: test-unlinkat
>
> The reason is that unlink("..") returns 0 without having done any side effects
> on the file system. Likewise for unlink("../..").
>
> Test program:
> ========================= foo.c ========================
> #include <errno.h>
> #include <stdio.h>
> #include <unistd.h>
> int main ()
> {
> int ret = unlink ("../..");
> printf ("%d %d\n", ret, errno);
> return 0;
> }
> ========================================================
>
> This prints
> -1 21 [EISDIR]
> on Linux, but
> 0 0
> on MacOS X.
Hi Bruno
That's pretty fundamental, but the POSIX spec for unlink leaves some
wiggle room:
The path argument shall not name a directory unless the process has
appropriate privileges and the implementation supports using unlink( )
on directories.
> Is the test too strict? Or should we add a workaround to lib/unlink.c
> and lib/unlinkat.c? The workaround could consist in testing whether the
> file name is ".." or ends in "/..".
My feeling is that the test should not be weakened, since allowing
unlink to succeed on any directory (and especially one like ".", "..", etc)
feels fundamentally flawed.
I wouldn't mind additional run-time code to detect that flaw
and map it to sensible return and errno values,
as long as it impacts only MacOS systems.
