Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <42C14C94.2040809@byu.net> Date: Tue, 28 Jun 2005 07:11:48 -0600 From: Eric Blake User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: cygwin AT cygwin DOT com, bug-coreutils AT gnu DOT org Subject: Re: ls when acl() is busy [was: ls slow on top-level directory] References: <062820050324 DOT 16993 DOT 42C0C2EB00001A5B0000426122007610640A050E040D0C079D0A AT comcast DOT net> <20050628083433 DOT GC5174 AT calimero DOT vinschen DOT de> In-Reply-To: <20050628083433.GC5174@calimero.vinschen.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes -----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 AT byu DOT 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/