[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: unlink test failure on MacOS X
From: |
Jim Meyering |
Subject: |
Re: unlink test failure on MacOS X |
Date: |
Mon, 15 Mar 2010 18:18:51 +0100 |
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.