[1.7] rename/renameat error

Eric Blake ebb9@byu.net
Tue Sep 22 21:02:00 GMT 2009


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



More information about the Cygwin mailing list