Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Tue, 28 Jun 2005 10:34:33 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
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]
Message-ID: <20050628083433.GC5174@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com, bug-coreutils AT gnu DOT org
Mail-Followup-To: cygwin AT cygwin DOT com, bug-coreutils AT gnu DOT org
References: <062820050324 DOT 16993 DOT 42C0C2EB00001A5B0000426122007610640A050E040D0C079D0A AT comcast DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <062820050324.16993.42C0C2EB00001A5B0000426122007610640A050E040D0C079D0A@comcast.net>
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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin AT cygwin DOT com
Red Hat, Inc.

--
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/