This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


-----BEGIN PGP SIGNED MESSAGE-----
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             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
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

iD8DBQFCwUyU84KuGfSFAYARAv1LAKCv6/91rsdc6BuhqTLbiAH98xFbDACglftF
RG9tds5stI9j4Ak2XLPS3no=
=sciN
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]