Mail Archives: cygwin/2009/09/22/17:02:53
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
- Raw text -