Re: ls when acl() is busy [was: ls slow on top-level directory]
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@cygwin.com Red Hat, Inc. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls when acl() is busy [was: ls slow on top-level directory]
-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 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. POSIX already requires the ' ' vs. '+' designator when a file has alternate access control (well, it only requires that the alternate access be listed as a printing character, but then recommends using '+' because it correctly implies that a file with ACLs may be more accessible to some other user than what was implied by the rest of the mode listing for the current user), and ls already implements this. Any script that tries to parse ls output is inherently non-portable to begin with. My only change would be adding '?' as the choice of printing character to indicate the indeteriminate nature of whether acls apply, and I don't think it violates POSIX or makes parsing ls output any harder than it already was. 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. Certainly less intrusive, but also potentially misleading. The point of a new character is to make it obvious that ls was unable to determine if there are ACLs, rather than that the file has no alternate access. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwUyU84KuGfSFAYARAv1LAKCv6/91rsdc6BuhqTLbiAH98xFbDACglftF RG9tds5stI9j4Ak2XLPS3no= =sciN -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls when acl() is busy [was: ls slow on top-level directory]
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. Certainly less intrusive, but also potentially misleading. The point of a new character is to make it obvious that ls was unable to determine if there are ACLs, rather than that the file has no alternate access. 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... 2. Probability. If the file is busy there's good chance that the file has an ACL. I view the '+' as a reminder that there's more to it than what is shown and I think that would be right thing to convey for busy files. I think this behaviour would be the least surprising... -- /Lasse ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls when acl() is busy [was: ls slow on top-level directory]
[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 hitab 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 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
