Bruno Haible wrote:
> Gary V. Vaughan wrote:
>>> ix86 SLED 10 gcc 4.1.2 (fchownat, rename, renameat)
>
> I'm seeing this failure on a Linux/x86 machine (SUSE Linux Enterprise Server
> 10,
> Linux 2.6.16.60, glibc 2.4):
>
> test-chown.h:79: assertion failed
> FAIL: test-fchownat
>
> The call that fails is
>
> ASSERT (func ("", -1, -1) == -1);
>
> in other words
>
> ASSERT (fchownat (3, "", -1, -1, 0) == -1);
>
> The test is right, because POSIX:2008 says about chown, fchownat:
> "These functions shall fail if:
> [ENOENT]
> A component of path does not name an existing file or path is an
> empty string."
>
> The function fchownat, on this platform, comes from glibc:
>
> $ nm test-fchownat|grep chown
> 0804c320 t do_chown
> 0804c2e0 t do_lchown
> U fchownat@@GLIBC_2.4
> 0804b370 t test_chown
> 08048e10 t test_lchown
>
> and strace shows this system call:
>
> chown32("/proc/self/fd/3/", -1, -1) = 0
>
> So the bug is in glibc. It was fixed there on 2009-10-30, following the
> report at <http://sources.redhat.com/bugzilla/show_bug.cgi?id=10609>.
>
> This fixes it for me. Jim, is this OK to push?
>
>
> 2010-11-12 Bruno Haible <br...@clisp.org>
>
> openat: Work around glibc bug with fchownat() and empty file names.
> * m4/openat.m4 (gl_FUNC_FCHOWNAT_EMPTY_FILENAME_BUG): New macro.
> (gl_FUNC_FCHOWNAT): Invoke it.
> * lib/fchownat.c (rpl_fchownat): Handle the empty file name specially.
> * doc/posix-functions/fchownat.texi: Document the glibc bug.
> Reported by Gary V. Vaughan <g...@gnu.org>.
Yes, that looks perfect. Thank you.
