[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: Corinna Vinschen
Subject: Re: ls when acl() is busy [was: ls slow on top-level directory]
Date: Tue, 28 Jun 2005 10:34:33 +0200
User-agent: Mutt/1.4.2i

On Jun 28 03:24, Eric Blake wrote:
> [bug-coreutils: posting this cygwin question upstream]
> Corinna Vinschen wrote:
> > Along these lines, we had a short discussion on the developers list
> > and we're wondering if it's necessary that ls prints this error message
> > at all.  The message is generated after a stat() already succeeded and
> > a follow up acl() call returns -1.  To say it with Dave Korn's words:
> > 
> > ISTM that ls has all the information it should need to DTRT - a successful
> > call to stat(), a return value of -1 from acl() and (I would hope that)
> > errno has EACCES(*) from the ERROR_SHARING_VIOLATION return should let it
> > deduce 'the file exists but is locked', shouldn't it?
> >
> > (*) actually EBUSY.
> > 
> > 
> > Eric?
> 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.

I think this is a corner case anyway, and it's pretty Cygwin/Windows
related.  The core problem is that on WIndows, some file metadata is
locked together with the file data when a process locks a file exclusively.
So, for instance, you can get the file size, but not the permissions,
the ACL.

The EBUSY only happens because stat() tries very hard to get *some*
information about a file and returns a (mostly) valid stat record
even if it couldn't determine all information.  acl() on the other hand
really needs access to the file to get the ACL.  So stat() works, but
acl() fails.  Very unfortunate, I admit.

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.


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

reply via email to

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