Hi, In <http://lists.gnu.org/archive/html/bug-gnulib/2008-12/msg00068.html> and <http://lists.gnu.org/archive/html/bug-gnulib/2008-12/msg00273.html> it was reported that the 'flock' tests fail on MacOS X 10.5. This is still the case today:
test-flock.c:80: assertion failed /bin/sh: line 1: 62455 Abort trap FAIL: test-flock In <http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00415.html> it was reported that the 'flock' tests fail on Solaris 10. This is still the case today: test-flock.c:62: assertion failed bash: line 5: 16978 Abort (core dumped) EXEEXT='' srcdir='.' ${dir}$tst FAIL: test-flock There was no reaction to these reports. So the 'flock' module is apparently unmaintained? Regarding the MacOS X failure, I think most programs can live without flock() rejecting invalid arguments. Therefore the best solution is to comment out the part of the test that is revealed too strict. Regarding the Solaris failure - an attempt to set a shared lock where an exclusive lock is already set - it should fail according to the Solaris manual page. Bug in Solaris. It fails on Linux, but - according to the Linux manual page - should succeed. Bug in Linux. So this test is best commented out on all platforms. I'm applying this. With this, the test succeeds on MacOS X and still fails on Solaris - must be a bug in gnulib's flock replacement or in Solaris' fcntl implementation; to be investigated. 2010-03-14 Bruno Haible <br...@clisp.org> * tests/test-flock.c (test_exclusive): Comment out a test that causes portability problems. Instead use a simpler test. (main): Check that invalid arguments are rejected only on Linux. --- tests/test-flock.c.orig Mon Mar 15 02:54:34 2010 +++ tests/test-flock.c Mon Mar 15 02:54:24 2010 @@ -58,9 +58,31 @@ fd2 = open (file, O_RDWR, 0644); ASSERT (fd2 >= 0); - r = flock (fd2, LOCK_SH | LOCK_NB); + r = flock (fd2, LOCK_EX | LOCK_NB); ASSERT (r == -1); /* Was unable to acquire a second exclusive lock. */ +#if 0 + /* The Linux manual page of flock(2) says: + "A process may only hold one type of lock (shared or exclusive) on a + file. Subsequent flock() calls on an already locked file will convert + an existing lock to the new lock mode." + So, the call below should convert the exclusive lock for fd to a shared + and thus succeeds. The fact that it doesn't but instead fails is + apparently a bug. */ + /* The Solaris manual page of flock(2) says: + "More than one process may hold a shared lock for a file at any given + time, but multiple exclusive, or both shared and exclusive, locks may + not exist simultaneously on a file. ... + Requesting a lock on an object that is already locked normally causes + the caller to block until the lock may be acquired. If LOCK_NB is + included in operation, then this will not happen; instead, the call + will fail and the error EWOULDBLOCK will be returned." + So, the call below should fail and set errno to EWOULDBLOCK. The fact + that it succeeds is apparently a bug. */ + r = flock (fd2, LOCK_SH | LOCK_NB); + ASSERT (r == -1); +#endif + ASSERT (flock (fd, LOCK_UN) == 0); ASSERT (close (fd2) == 0); } @@ -76,7 +98,9 @@ ASSERT (fd >= 0); ASSERT (write (fd, "hello", 5) == 5); - /* Some impossible operation codes which should never be accepted. */ +#if defined __linux__ + /* Invalid operation codes are rejected by the Linux implementation and by + the gnulib replacement, but not by the MacOS X implementation. */ ASSERT (flock (fd, LOCK_SH | LOCK_EX) == -1); ASSERT (errno == EINVAL); ASSERT (flock (fd, LOCK_SH | LOCK_UN) == -1); @@ -85,6 +109,7 @@ ASSERT (errno == EINVAL); ASSERT (flock (fd, 0) == -1); ASSERT (errno == EINVAL); +#endif test_shared (file, fd); test_exclusive (file, fd);
