bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test results on NetBSD 7.0


From: Bruno Haible
Subject: Re: test results on NetBSD 7.0
Date: Wed, 16 Aug 2017 10:14:48 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-91-generic; KDE/5.18.0; x86_64; ; )

Paul Eggert wrote:
> > FAIL: test-renameat
> > ===================
> > 
> > ../../gltests/test-rename.h:525: assertion 'stat (BASE "file", &st) == 0' 
> > failed
> > FAIL test-renameat (exit status: 134)
> > 
> > FAIL: test-renameat2
> > ====================
> 
> These appear to be because Gnulib tests are too strict about renameat. They 
> should allow the NetBSD behavior, because it's better than the behavior that 
> POSIX requires. I installed the first attached patch to try to fix this.

Thanks. I confirm that these test failures are now gone.

I'm adding a doc update
  1) to be precise about the NetBSD version (since these OSes evolve, I try to
     avoid statements about "NetBSD" as a whole),
  2) to note that the effect of CPPFLAGS="-D_XOPEN_SOURCE=500" is that
     /usr/include/stdio.h redirects the 'rename' function to '__posix_rename',
     with the effect that configure
       - no longer defines RENAME_HARD_LINK_BUG,
       - sets REPLACE_RENAME and REPLACE_RENAMEAT to 0 instead of 1.

But I'm confused: Isn't the problem which you described in the "not fixed
by gnulib" section the same as the bug tested for by the RENAME_HARD_LINK_BUG
test in m4/rename.m4 ? Both are about hard links to the same file, no?
One is caught by the configure test (and even not present any more when
-D_XOPEN_SOURCE=500 is used), and the other one requires a workaround in
tests/test-rename.h. What is the difference, then?


2017-08-16  Bruno Haible  <address@hidden>

        rename, renameat: Update doc regarding NetBSD.
        * doc/posix-functions/rename.texi: Clarify that when using
        -D_XOPEN_SOURCE=500 on NetBSD 7.0, the hard link bug is gone.
        * doc/posix-functions/renameat.texi: Be more precise about NetBSD
        version.

diff --git a/doc/posix-functions/rename.texi b/doc/posix-functions/rename.texi
index b024b96..12c3be4 100644
--- a/doc/posix-functions/rename.texi
+++ b/doc/posix-functions/rename.texi
@@ -28,7 +28,7 @@ Solaris 9.
 @item
 This function incorrectly reduces the link count when comparing two
 spellings of a hard link on some platforms:
-NetBSD 1.6, Cygwin 1.5.x.
+NetBSD 1.6, NetBSD 7.0 without @code{-D_XOPEN_SOURCE=500}, Cygwin 1.5.x.
 @item
 This function will not always replace an existing destination on some
 platforms:
@@ -60,7 +60,7 @@ is counter-intuitive, so on some systems, @code{rename} fails 
with
 @code{ENOTDIR} if either argument is a symlink with a trailing slash:
 glibc, OpenBSD, Cygwin 1.7.
 @item
-POSIX requires that @code{renameat} do nothing and return 0 if the
+POSIX requires that @code{rename} do nothing and return 0 if the
 source and destination are hard links to the same file.  This behavior
 is counterintuitive, and on some systems @code{renameat} is a no-op in
 this way only if the source and destination identify the same
@@ -68,7 +68,7 @@ directory entry.  On these systems, for example, although 
renaming
 @file{./f} to @file{f} is a no-op, renaming @file{f} to @file{g}
 deletes @file{f} when @file{f} and @file{g} are hard links to the same
 file:
-NetBSD.
+NetBSD 7.0.
 @item
 After renaming a non-empty directory over an existing empty directory,
 the old directory name is still visible through the @code{stat} function
diff --git a/doc/posix-functions/renameat.texi 
b/doc/posix-functions/renameat.texi
index dd97132..073c179 100644
--- a/doc/posix-functions/renameat.texi
+++ b/doc/posix-functions/renameat.texi
@@ -47,7 +47,7 @@ directory entry.  On these systems, for example, although 
renaming
 @file{./f} to @file{f} is a no-op, renaming @file{f} to @file{g}
 deletes @file{f} when @file{f} and @file{g} are hard links to the same
 file:
-NetBSD.
+NetBSD 7.0.
 @item
 After renaming a non-empty directory over an existing empty directory,
 the old directory name is still visible through the @code{stat} function




reply via email to

[Prev in Thread] Current Thread [Next in Thread]