X-Recipient: archive-cygwin@delorie.com
X-Spam-Check-By: sourceware.org
Date: Thu, 6 Mar 2008 16:27:05 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: bug with touch t/
Message-ID: <20080306152705.GU18407@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <loom.20080304T214047-23@post.gmane.org> <20080305183640.GI18407@calimero.vinschen.de> <47CFEE38.5040905@byu.net> <20080306132748.GP18407@calimero.vinschen.de> <47CFF263.90804@byu.net> <20080306134546.GQ18407@calimero.vinschen.de> <47CFF979.6080201@byu.net> <20080306142614.GR18407@calimero.vinschen.de> <loom.20080306T144346-788@post.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <loom.20080306T144346-788@post.gmane.org>
User-Agent: Mutt/1.5.16 (2007-06-09)
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie.com@cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com

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/