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/
