Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: ericblake AT comcast DOT net (Eric Blake)
To: cygwin AT cygwin DOT com, bug-coreutils AT gnu DOT org
Subject: ls when acl() is busy [was: ls slow on top-level directory]
Date: Tue, 28 Jun 2005 03:24:27 +0000
Message-Id: <062820050324.16993.42C0C2EB00001A5B0000426122007610640A050E040D0C079D0A@comcast.net>

[bug-coreutils: posting this cygwin question upstream]

> On Jun 27 14:50, Will Parsons wrote:
> >   I notice that "ls" reports:
> > 
> > /bin/ls: hiberfil.sys: No such file or directory
> > /bin/ls: pagefile.sys: No such file or directory
> > 
> > "ls hi<tab>" completes to "ls hiberfil.sys", and shows the same message.
> > 
> > Could this have something to do with the slow response?
> 
> No, that's entirely unrelated.  In recent Cygwin snapshots the message
> from ls has changed to "Device or resource busy" and you get an ls
> output for these files.  It's just an open() on exclusively locked files
> which fails in the above cases.
> 
> 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
would be more work (the gnulib library file_has_acl already returns
-1 on failure, 0 on no ACL, and 1 on ACL; perhaps make it return
2 on indeterminate).  Should such a change be propagated to
coreutils and gnulib, or left as a cygwin-local patch?

--
Eric Blake


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