Re: bug with touch t/
On Thu, 6 Mar 2008 16:32:52 +0100, Corinna Vinschen wrote: On Mar 6 16:27, Corinna Vinschen wrote: On Mar 6 14:56, Eric Blake wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: But the flags are not O_RDONLY|O_CREAT. They are O_WRONLY|O_CREAT. I still think Linux is wrong - t/ is not an existing directory, so you can't claim that an attempt was made to open an existing directory with O_WRONLY. But I guess it is a bit ambiguous, since if t/ did exist, then opening t/. should indeed fail with EISDIR; at any rate, it is certainly more efficient to blindly reject O_WRONLY due to the trailing slash without even checking for the existence of t. In our case I added a special case to emit EISDIR, otherwise we would get ENOENT automatically (that's what STATUS_OBJECT_NAME_INVALID gets converted to). However, I'm somewhat puzzled that you used that bash example: $ : t/ bash: t/: Is a directory. If what you said is right, and if I revert the change to fhandler.cc, we would get a ENOENT in that case, too. And given your arguments, that should be correct. Do you agree? I should add that I'm still rather leaning towards the Linux behaviour. I tested this on Solaris 10, and it behaves again different. In both examples open(2) returns with ENOTDIR. And for what it's worth, on AIX 5.3 they succeed: open(t/, O_WRONLY|O_CREAT|O_LARGEFILE)= 3 open(t/, O_RDONLY|O_CREAT|O_LARGEFILE)= 3 But: open(t/., O_WRONLY|O_CREAT|O_LARGEFILE) Err#2 ENOENT open(t/., O_RDONLY|O_CREAT|O_LARGEFILE) Err#2 ENOENT And so they do on Solaris 8: open64(t/, O_WRONLY|O_CREAT|O_LARGEFILE, 0666) = 3 open64(t/, O_RDONLY|O_CREAT|O_LARGEFILE, 0666) = 3 open64(t/., O_WRONLY|O_CREAT|O_LARGEFILE, 0666) Err#2 ENOENT open64(t/., O_RDONLY|O_CREAT|O_LARGEFILE, 0666) Err#2 ENOENT So it's the same on both OS and Linux is different. Michael -- 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/
Re: bug with touch t/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Lemke, Michael SZ/HZA-ZIOM1 on 3/7/2008 2:22 AM: | Do you agree? | I should add that I'm still rather leaning towards the Linux | behaviour. | I tested this on Solaris 10, and it behaves again different. In both | examples open(2) returns with ENOTDIR. For the record, Linux' behavior is vindicated - EISDIR on a nonexistent name with trailing slash and O_WRONLY is acceptable: https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index.tplsource=Llistname=austin-group-lid=11382 - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0Tzc84KuGfSFAYARAtppAJ91EyRvACm9QEYBLXaBA2/pv65tCwCeONs+ Vizcbz1bt70PlF9XoILqSYo= =ciKj -END PGP SIGNATURE- -- 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/
Re: bug with touch t/
On Mar 7 06:02, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Lemke, Michael SZ/HZA-ZIOM1 on 3/7/2008 2:22 AM: | Do you agree? | I should add that I'm still rather leaning towards the Linux | behaviour. | I tested this on Solaris 10, and it behaves again different. In both | examples open(2) returns with ENOTDIR. For the record, Linux' behavior is vindicated - EISDIR on a nonexistent name with trailing slash and O_WRONLY is acceptable: https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index.tplsource=Llistname=austin-group-lid=11382 Good to know. Thanks for your input! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: bug with touch t/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 3/5/2008 11:36 AM: | $ : t/ | t/: Is a directory. | | | Should be fixed in the new 1.5.25-11 test release. Yes, in 1.5.25-11, it is _correctly_ failing with ENOENT. But in CVS, it looks like you changed it to return EISDIR instead? http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.cc.diff?cvsroot=srcr1=1.313r2=1.314 POSIX requires ENOENT, not EISDIR (if neither 't' nor 't/' exist, and you are performing file name resolution for open(t/,O_RDONLY|O_CREAT), then the resolution should be performed as if it were open(t/.,O_RDONLY|O_CREAT) and fail with ENOENT since t is not a directory). EISDIR is reserved for cases like open(t/,O_WRONLY) when t/ already exists. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHz+4384KuGfSFAYARAtlLAKCIVIZQca059CICB6DIMg+AIr5XEQCfUGvM 41aotxz7nFUBCcakRNiMvYI= =Xqmd -END PGP SIGNATURE- -- 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/
Re: bug with touch t/
On Mar 6 06:14, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 3/5/2008 11:36 AM: | $ : t/ | t/: Is a directory. | | | Should be fixed in the new 1.5.25-11 test release. Yes, in 1.5.25-11, it is _correctly_ failing with ENOENT. But in CVS, it looks like you changed it to return EISDIR instead? http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.cc.diff?cvsroot=srcr1=1.313r2=1.314 POSIX requires ENOENT, not EISDIR (if neither 't' nor 't/' exist, and you are performing file name resolution for open(t/,O_RDONLY|O_CREAT), then the resolution should be performed as if it were open(t/.,O_RDONLY|O_CREAT) and fail with ENOENT since t is not a directory). EISDIR is reserved for cases like open(t/,O_WRONLY) when t/ already exists. I examined this situation on Linux. In Linux, touch tries to open t\ and open() returns EISDIR. The fact that you see an ENOENT is a result of touch trying to use other methods to set the time: Linux$ strace touch t/ [...] open(t/, O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY, 0666) = -1 EISDIR (Is a directory) futimesat(AT_FDCWD, t/, NULL) = -1 ENOENT (No such file or directory) When you look into the strace on Cygwin, you'll see a similar behaviour now. open returns with errno set to EISDIR, then touch tries to set the time neverthelss using a call to utimes(). Thus you get No such file or directory from utimes. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: bug with touch t/
On Mar 6 06:32, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 3/6/2008 6:27 AM: | | I examined this situation on Linux. In Linux, touch tries to open t\ | and open() returns EISDIR. The fact that you see an ENOENT is a result | of touch trying to use other methods to set the time: In other words, Linux does it wrong, too. I guess it's okay to be bug-compatible to Linux, since after all, we are trying to emulate Linux more than POSIX. SUSv3(*) says: [EISDIR] The named file is a directory and oflag includes O_WRONLY or O_RDWR. [ENOENT] O_CREAT is not set and the named file does not exist; or O_CREAT is set and either the path prefix does not exist or the path argument points to an empty string. Given these descriptions, I can't see anything wrong with that Linux behaviour. Corinna (*) http://www.opengroup.org/onlinepubs/009695399/functions/open.html -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: bug with touch t/
On Mar 6 07:02, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 3/6/2008 6:45 AM: | SUSv3(*) says: | | [EISDIR] | The named file is a directory and oflag includes O_WRONLY or O_RDWR. | [ENOENT] | O_CREAT is not set and the named file does not exist; or O_CREAT is | set and either the path prefix does not exist or the path argument | points to an empty string. | | Given these descriptions, I can't see anything wrong with that Linux | behaviour. By those SUSv3 rules (which are identical to POSIX), open(t/, O_RDONLY|O_CREAT) when t does not exist falls under ENOENT, not EISDIR. In POSIX 2004, path resolution requires that if a trailing slash is present, resolution is performed as if by t/., making t a path prefix which is not present. And in the draft POSIX 200x, the wording has been made more explicit that when doing path resolution, if there is a trailing slash but the text before the slash does not name an existing directory, then it fails with ENOENT. But on Linux: Linux$ strace touch t/ ~ [...] ~ open(t/, O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY, 0666) = -1 EISDIR (Is a directory) But the flags are not O_RDONLY|O_CREAT. They are O_WRONLY|O_CREAT. That's why this falls under EISDIR under SUSv3 rules, afaics. Which chapter in the austin doc are you refering to? I can't find this re-wording for some reason. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: bug with touch t/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 3/6/2008 6:45 AM: | SUSv3(*) says: | | [EISDIR] | The named file is a directory and oflag includes O_WRONLY or O_RDWR. | [ENOENT] | O_CREAT is not set and the named file does not exist; or O_CREAT is | set and either the path prefix does not exist or the path argument | points to an empty string. | | Given these descriptions, I can't see anything wrong with that Linux | behaviour. By those SUSv3 rules (which are identical to POSIX), open(t/, O_RDONLY|O_CREAT) when t does not exist falls under ENOENT, not EISDIR. In POSIX 2004, path resolution requires that if a trailing slash is present, resolution is performed as if by t/., making t a path prefix which is not present. And in the draft POSIX 200x, the wording has been made more explicit that when doing path resolution, if there is a trailing slash but the text before the slash does not name an existing directory, then it fails with ENOENT. But on Linux: Linux$ strace touch t/ ~ [...] ~ open(t/, O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY, 0666) = -1 EISDIR (Is a directory) ~ futimesat(AT_FDCWD, t/, NULL) = -1 ENOENT (No such file or directory) Linux is returning the wrong errno for open, according to SUSv3/POSIX. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHz/l584KuGfSFAYARAuyMAJ99nmo2dcOG9EmMpKhR7gPJkelsbgCguHZE YfHGhOThDIucOBwO2H9kkrA= =5I6D -END PGP SIGNATURE- -- 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/
Re: bug with touch t/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 3/6/2008 6:27 AM: | | I examined this situation on Linux. In Linux, touch tries to open t\ | and open() returns EISDIR. The fact that you see an ENOENT is a result | of touch trying to use other methods to set the time: In other words, Linux does it wrong, too. I guess it's okay to be bug-compatible to Linux, since after all, we are trying to emulate Linux more than POSIX. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHz/Ji84KuGfSFAYARAnIiAJ9xPRrJA+jR1fGjyNPnOHCjFYKXOgCdGuUs OrtEETuRVYQfTwDjdkn7JZc= =uFx+ -END PGP SIGNATURE- -- 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/
Re: bug with touch t/
Corinna Vinschen corinna-cygwin at cygwin.com writes: But the flags are not O_RDONLY|O_CREAT. They are O_WRONLY|O_CREAT. I still think Linux is wrong - t/ is not an existing directory, so you can't claim that an attempt was made to open an existing directory with O_WRONLY. But I guess it is a bit ambiguous, since if t/ did exist, then opening t/. should indeed fail with EISDIR; at any rate, it is certainly more efficient to blindly reject O_WRONLY due to the trailing slash without even checking for the existence of t. That's why this falls under EISDIR under SUSv3 rules, afaics. Maybe it's worth asking the Austin Group for clarification? I already asked about Linux's decision to make rename(symlink-to-dir/,other) and rmdir (symlink-to-dir/) both fail with ENOTDIR, even though POSIX states those should succeed (by operating on the underlying dir and leaving symlink-to-dir dangling), but the Austin group shot that down by claiming that Linux is buggy for using that particular errno and should be using something like ENOTSUP instead. Which chapter in the austin doc are you refering to? I can't find this re-wording for some reason. The rewording for path resolution is in section XBD 4.12 (page 109 in draft 4 of the 200x spec). You have to use your Austin login to download the draft. Draft 5 will be coming out soon, and the goal is to finalize the formal release of POSIX 200x by the end of this year (probably calling it POSIX 2008). But you can also see publicly this particular rewording in the Interp against POSIX 2001: https://www.opengroup.org/austin/interps/uploads/40/4059/AI-016.txt -- 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/
Re: bug with touch t/
On Mar 6 14:56, Eric Blake wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: But the flags are not O_RDONLY|O_CREAT. They are O_WRONLY|O_CREAT. I still think Linux is wrong - t/ is not an existing directory, so you can't claim that an attempt was made to open an existing directory with O_WRONLY. But I guess it is a bit ambiguous, since if t/ did exist, then opening t/. should indeed fail with EISDIR; at any rate, it is certainly more efficient to blindly reject O_WRONLY due to the trailing slash without even checking for the existence of t. In our case I added a special case to emit EISDIR, otherwise we would get ENOENT automatically (that's what STATUS_OBJECT_NAME_INVALID gets converted to). However, I'm somewhat puzzled that you used that bash example: $ : t/ bash: t/: Is a directory. If what you said is right, and if I revert the change to fhandler.cc, we would get a ENOENT in that case, too. And given your arguments, that should be correct. Do you agree? Maybe it's worth asking the Austin Group for clarification? I already asked Maybe, but the upcoming 1.5.25 bugfix release will not be affected by this. Which chapter in the austin doc are you refering to? I can't find this re-wording for some reason. The rewording for path resolution is in section XBD 4.12 (page 109 in draft 4 of the 200x spec). I have only Draft 3 here, but I see what you mean. Nevertheless, what about the `: t/' case above? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: bug with touch t/
On Mar 6 16:27, Corinna Vinschen wrote: On Mar 6 14:56, Eric Blake wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: But the flags are not O_RDONLY|O_CREAT. They are O_WRONLY|O_CREAT. I still think Linux is wrong - t/ is not an existing directory, so you can't claim that an attempt was made to open an existing directory with O_WRONLY. But I guess it is a bit ambiguous, since if t/ did exist, then opening t/. should indeed fail with EISDIR; at any rate, it is certainly more efficient to blindly reject O_WRONLY due to the trailing slash without even checking for the existence of t. In our case I added a special case to emit EISDIR, otherwise we would get ENOENT automatically (that's what STATUS_OBJECT_NAME_INVALID gets converted to). However, I'm somewhat puzzled that you used that bash example: $ : t/ bash: t/: Is a directory. If what you said is right, and if I revert the change to fhandler.cc, we would get a ENOENT in that case, too. And given your arguments, that should be correct. Do you agree? I should add that I'm still rather leaning towards the Linux behaviour. I tested this on Solaris 10, and it behaves again different. In both examples open(2) returns with ENOTDIR. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: bug with touch t/
On Mar 4 21:47, Eric Blake wrote: According to POSIX (and as implemented on Linux): $ rm -Rf t $ touch t/ touch: setting times of `t/': No such file or directory $ : t/ t/: Is a directory. The ENOENT failure is correct, since you are using the syntax to open (or create) a directory but are not going through mkdir. However, on cygwin, both commands mistakenly create the regular file 't'. This is also an issue with touch 't\' which likewise mistakenly creates the regular file 't' by treating \ as an alternate directory separator - as a result, the current git checkout of autoconf is triggering spurious failures when testing whether the file system supports \ embedded in file names rather than as directory separators. Should be fixed in the new 1.5.25-11 test release. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
bug with touch t/
According to POSIX (and as implemented on Linux): $ rm -Rf t $ touch t/ touch: setting times of `t/': No such file or directory $ : t/ t/: Is a directory. The ENOENT failure is correct, since you are using the syntax to open (or create) a directory but are not going through mkdir. However, on cygwin, both commands mistakenly create the regular file 't'. This is also an issue with touch 't\' which likewise mistakenly creates the regular file 't' by treating \ as an alternate directory separator - as a result, the current git checkout of autoconf is triggering spurious failures when testing whether the file system supports \ embedded in file names rather than as directory separators. -- 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/
