ls when acl() is busy [was: ls slow on top-level directory]
Wed Jun 29 04:49:00 GMT 2005
At 04:03 PM 6/28/2005, you wrote:
>Eric Blake wrote:
>>According to Corinna Vinschen on 6/28/2005 2:34 AM:
>>>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.
>IMO, it should be the other way around, i.e. no error but a '+' to
>signify an ACL, for two reasons:
>1. Transperency. Since the UNIX permissions are emulated, one could
>argue that all files should have the '+' displayed...
Traditional UNIX permissions have always been represented by "drwxrwxrwx"
permission displays (yes, I know "s" and "t" are possible options in some
of the above locations). ACLs are just different kinds of permissions that
don't obviously map into the traditional UNIX permissions. UNIX permissions
do not imply or require the use of ACLs so using a '+' for all files would
misleading. Using '+' as you mentioned for all files displayed by Cygwin's
'ls' would actually make it less transparent, not more.
>2. Probability. If the file is busy there's good chance that the file
>has an ACL.
Actually no. It just means the file is locked. As Corinna pointed out,
there is no distinction in Windows between the meta data and the file.
If the file is locked, the meta data is too and vice versa. So a locked
file tells you nothing about the existence of ACLs on this file.
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin