Re: ls when acl() is busy

[Corinna Vinschen]

On Jun 30 10:16, Jim Meyering wrote:
> address@hidden (Eric Blake) wrote:
> ...
> > 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
> 
> If acl failing with EBUSY is a reliable indicator that there is
> indeed an ACL, then using the `+' mark sounds best.

No, it's not a reliable indicator.  Let me explain.

Windows (resp. the NTFS filesystem) is always using ACLs.  The Cygwin
implementation of POSIX permissions utilizes the owner/group/everyone
ACL entries for the POSIX permissions bits. 

If only these owner/group/everyone ACL entries are present, then acl()
returns with MIN_ACL_ENTRIES which indicates that only POSIX permissions
are present and ls does not print the '+'.  If more ACL entries are
present, the number returned by acl() is > MIN_ACL_ENTRIES and ls prints
a '+'.

When a file is exclusivly locked by another application, then the
access to the ACL is entirely impossible.  So we don't know anything
about the actual ACL.  Cygwin's stat() returns with the POSIX permission
bits set to 000 in this case (which is still somewhat unfortunate, but
at least reflects the current situation from the processes' perspective).

So in some way the '+' is as wrong as the ' ', because we just don't
know.  I understand Eric's idea of adding a '?' indicator for this
case, I just don't think it really helps the user.

Whatever the result of this discussion is, the most important part is,
that the failing call to acl() shouldn't result in ls printing an error
message in this case.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:address@hidden
Red Hat, Inc.