Re: unlink test failure on MacOS X

[Jim Meyering]

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.