This is the mail archive of the
cygwin
mailing list for the Cygwin project.
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/