[Top][All Lists]

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

Re: ls when acl() is busy [was: ls slow on top-level directory]

From: Eric Blake
Subject: Re: ls when acl() is busy [was: ls slow on top-level directory]
Date: Tue, 28 Jun 2005 07:11:48 -0600
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Hash: SHA1

According to Corinna Vinschen on 6/28/2005 2:34 AM:
>>Hmm - murky waters here.  It would be a simple one-line fix to
>>coreutils/lib/acl.c to ignore EBUSY as a non-error, and POSIX has
>>no requirements per se that a failure of acl() should imply a failure
>>of ls(1).  Should a busy file be conservatively treated as having an
>>ACL (designated with '+' in the mode string) or left alone without
>>one (designated with ' ' in the mode string) when cygwin is unable
>>to query Windows without blocking for an undue length of time?
>>Right now, I'm almost leaning for a third option, and displaying '?'
>>or some other character to mean unable to determine, but that
> I'd rather not do this.  The output of ls is already complex enough
> and people having scripts munging ls output (well, just a thought...)
> would have a hard time to find the "bug" in their scripts.

POSIX already requires the ' ' vs. '+' designator when a file has
alternate access control (well, it only requires that the alternate access
be listed as a printing character, but then recommends using '+' because
it correctly implies that a file with ACLs may be more accessible to some
other user than what was implied by the rest of the mode listing for the
current user), and ls already implements this.  Any script that tries to
parse ls output is inherently non-portable to begin with.  My only change
would be adding '?' as the choice of printing character to indicate the
indeteriminate nature of whether acls apply, and I don't think it violates
POSIX or makes parsing ls output any harder than it already was.

> However, IMHO, ls should be changed to just print no error message,
> if file_has_acl() returns -1 and errno is set to EBUSY, and the file
> should simply be treated as a file with no ACL.  That's the least
> intrusive way, IMHO.

Certainly less intrusive, but also potentially misleading.  The point of a
new character is to make it obvious that ls was unable to determine if
there are ACLs, rather than that the file has no alternate access.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


reply via email to

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