This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [1.7] rename/renameat error

Eric Blake <ebb9 <at>> writes:

> > > > Cygwin 1.7 is
> > > > detecting this situation (which is a step up from 1.5 which did the 
> > > > 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 
> looking at where to patch things.

I've got a patch in testing for both of these issues.  But while looking at, 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 

Eric Blake

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]