X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 	tests=AWL,BAYES_00,J_CHICKENPOX_33,J_CHICKENPOX_42,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: [1.7] rename/renameat error
Date: Tue, 22 Sep 2009 21:02:10 +0000 (UTC)
Lines: 35
Message-ID:  <loom.20090922T225033-801@post.gmane.org>
References:  <4AA52B5E DOT 8060509 AT byu DOT net> <20090907192046 DOT GA12492 AT calimero DOT vinschen DOT de> <loom DOT 20090909T005422-847 AT post DOT gmane DOT org> <loom DOT 20090909T183010-83 AT post DOT gmane DOT org>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Eric Blake <ebb9 <at> byu.net> writes:

> > > > Cygwin 1.7 is
> > > > detecting this situation (which is a step up from 1.5 which did the 
rename
> > > > anyways), but sets errno to EBUSY instead of EINVAL.
> > > 
> > > Thanks for catching.  Feel free to fix the rename function accordingly.
> > 
> > OK, I'll look into it (I don't know how large the patch will be, yet).
> 
> And link("a","f/.") should not create "f" as a regular file, either.  I'm 
still 
> looking at where to patch things.

I've got a patch in testing for both of these issues.  But while looking at 
path.cc, I've noticed a couple of things:

The code doesn't do a very good job of remembering lengths it has already 
seen.  For example, with relative paths, the code in normalize_posix_path does 
cwd.get, then strchr; it seems like since cwd.get already knows how many bytes 
it copied, that a simple API modification would pass that information back to 
the caller so that the caller doesn't have to use strchr to find the end of the 
string.  Anything we can do to avoid rescanning strings of known length will 
provide speedups in path handling.

I'm also wondering whether it is time to finally emulate Linux by requiring 
that when doing pathname resolution of 'a/..', that 'a' actually exist (either 
as a directory or a symlink to directory), instead of silently ignoring that 
part of the string.  Should I go ahead and spend time working up a patch for 
this?

-- 
Eric Blake



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple