[Top][All Lists]

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

Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (includ

From: sci-fi
Subject: Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)
Date: Mon, 25 Sep 2006 17:25:01 -0500
User-agent: Unison/1.7.7

[let me see if gmane lets me reply to posts]

On 2006-09-25 08:10:03 -0500, Jim Meyering <address@hidden> said:

<address@hidden> wrote:
I am new to this list, but not at all new to building and using
open source projects.  (Please CC me if needed as I haven't yet
joined this list.  Or I think I can access and post via
news.gmane.org with regular newsreaders.)

I built coreutils-6.2 on Darwin-8.7.0 ("Tiger" 10.4.7 and the
latest XCode-2.4).  I actually have installed coreutils-5.97 to
compare with.

5.97 seems to work fine, but 6.2 seems to have many things wrong.

Most notably the new 'ls' in 6.2 is acting very very strange.
We get double listings in 'long' mode of every file, with
exactly the first set saying "No such file or directory",
including the dot-dirs.  The second set lists each file/dir as

I am attaching a sample to show you what I mean here.  Please
find the archive named 'coreutils-6.2-bugs.tar.bz2'.  It should
expand to create these files:

-rw-r--r-- 1 root wheel 1957313 Sep 25 00:43 config.log
-rw-r--r-- 1 root wheel   31244 Sep 25 00:43 config_consolelog.txt
-rw-r--r-- 1 root admin   29725 Sep 25 00:51 ls_whoops_consolelog.txt
-rw-r--r-- 1 root wheel   67706 Sep 25 00:45 make_consolelog.txt
-rw-r--r-- 1 root wheel   55908 Sep 25 00:49 makecheck_consolelog.txt

Thank you for the complete bug report!

I'm obviously quite worried about releasing this code to Darwin
users, so I thought I better do a bit of hollarin' here.  ;)

You're right to be cautious.
The problems involving ls, cp, and install are all due
to the fact that Darwin's acl_get_file function (used
in coreutils' lib/acl.c) is not behaving as advertised:
it's returning NULL and setting errno to ENOENT for a file
that *does* exist.  However, the man page says it does that only
for files that do not exist.  When a function like that reports
a failure, coreutils programs report it and exit nonzero, and
that's why you're seeing so many diagnostics and test failures.

This might explain other ACL problems I've read about at other sites.
I am attempting to sniff around Apple's maillists to see if this is a
known bug.  We are getting browser "disconnect" errors ATM while
waiting for their archives to load-up.  ~sigh~

I am also trying to pull the xnu project from 10.4.7.ppc and take a
peek that way.  I don't know if xnu can be fetch via CVS there.

Unfortunately there is no way us mere mortals (free ADC accounts) are
allowed to search their Bug Submissions database.  One can only keep
track of bugs one has filed under one's id there.

Using the very latest version from coreutils and gnulib,
when I turn off ACL support altogether (comment out the USE_ACL
definition in lib/config.h), all of the tests pass except tests/dd/misc.

That failure appears to be due to another Darwin-specific bug:
The open flag, O_NOFOLLOW is defined, yet open doesn't honor the
semantics we've come to expect for that flag.  That makes the test
of dd's new iflag=nofollow option fail.
The only mitigating factor is that O_NOFOLLOW is not yet documented in
their open man page:  the definition may have slipped into their
system headers before library support was completed.

btw fwiw 'apropos O_NOFOLLOW' shows 'nothing appropriate' here,
supporting your note about it not being documented.
otoh 'apropos acl_get_file' does show the manpage available.

Unfortunately, O_NOFOLLOW (when present) is an important key to avoiding
certain types of race conditions.  Defining the symbol yet letting
open ignore it is *bad*.  Here's a small program to demonstrate the bug.
Run the command in the comment.  If it prints "bug", then your system's
open function is buggy.
$ cat o_nofollow.c
/* rm -f s f; cc o_nofollow.c && { touch f; ln -s f s; ./a.out || echo bug; } */
# define _GNU_SOURCE 1
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
main ()
  int fd = open ("s", O_RDONLY|O_NOFOLLOW);
  return 0 < fd;

Yep, it prints 'bug'.  And this is with coreutils-5.97 btw.

However, the good news is that this led me to discover a bug in gnulib's
test for just this type of brokenness.  Its fcntl_h module tests for a
nonfunctional O_NOFOLLOW, but the test had a typo.  I've just checked
in a fix for that.

So now, all tests now pass, using the very latest, and with the hack
to disable ACL support.  I suppose we'll need an added run-test
to detect the acl_get_file brokenness.

Thank you for the detailed explanations.  If nothing shows up on the
Darwin maillists (or I give up waiting ;) ), I will file a Bug at ADC.
Would you mind if I quote your entire message here, please?

Let me also check their CVS and/or new MacOSForge sites (the latter has
been down for nearly a week, still is as of this typing ~double~sigh~).

I will pull coreutils and gnulib from CVS also and report back.

Thank you again.


reply via email to

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