bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ls when acl() is busy [was: ls slow on top-level directory]


From: Eric Blake
Subject: ls when acl() is busy [was: ls slow on top-level directory]
Date: Tue, 28 Jun 2005 03:24:27 +0000

[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






reply via email to

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