At 02:24 PM 6/30/2005, you wrote:
>Larry Hall wrote:
>>At 04:03 PM 6/28/2005, you wrote:
>[SNIP]
>>>IMO, it should be the other way around, i.e. no error but a '+' to
>>>signify an ACL, for two reasons:
>>>
>>>1. Transperency. Since the UNIX permissions are emulated, one could
>>>argue that all fil
At 02:18 PM 6/30/2005, you wrote:
>Corinna Vinschen wrote:
>[SNIP]
>>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
Larry Hall wrote:
At 04:03 PM 6/28/2005, you wrote:
[SNIP]
IMO, it should be the other way around, i.e. no error but a '+' to
signify an ACL, for two reasons:
1. Transperency. Since the UNIX permissions are emulated, one could
argue that all files should have the '+' displayed...
Traditional
Corinna Vinschen wrote:
[SNIP]
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 unfo
On Jun 30 10:16, Jim Meyering wrote:
> [EMAIL PROTECTED] (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
> > o
[EMAIL PROTECTED] (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 tr
At 04:03 PM 6/28/2005, you wrote:
>Eric Blake wrote:
>>According to Corinna Vinschen on 6/28/2005 2:34 AM:
>>
>>>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
Eric Blake wrote:
According to Corinna Vinschen on 6/28/2005 2:34 AM:
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.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 6/28/2005 2:34 AM:
>>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 fai
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 gener
[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" completes to "ls hiberfil.sys", and shows
11 matches
Mail list logo
