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: [PATCH] Check for existence of the path before processing '..'

 Hello! Sorry for delayed replies, at home i'm not subscribed to Cygwin ML, and in Russia we had a holiday yesterday.

> Thanks for the patch.  The idea sounds good, and I think it's the right
> thing to do *not* to add this to normalize_win32_path, because the ..
> semantics on WINdows are so that a .. is allowed even if the parent
> doesn't exist.

 Yes, i agree. After all, POSIX rules apply to POSIX paths. And having Win32 paths in POSIX environment is kind of supernatural. :)

> I didn't test your patch so far, but I'm a bit puzzled about your
> performance claim: ~0.2 secs compared to what?  What's your test case?

 I don't remember exactly, but i've done something like 'time ls -l ../bin' after cd'ing to /usr/src.

> I mean, this tiny code snippet can't take 0.2 secs per single call,

 Yes, but:
 1. From strace it seems that 'ls -l' fstat()s every file with file name appended to the given path. And each file gets '..' in its path.
 2. Path conversion implies reading mount tables, symlinks, etc. I tried to imagine how this could be optimized, but found no simple solution. Because in general case this should also work for things like '/mnt/drive1/../symlink2/../drive3', across all mounts and symlinks. So, this solution is kind of balance between performance and simplicity.

 Actually, this even can be optimized by implementing a part-by-part path conversion, for example (imagine we get /usr/src/../bin as argument):
 1. Start conversion until we meet '..'. Remember this place.
 2. Convert '/usr/src' to Windows format, get 'C:\cygwin64\usr\src'.
 3. Check for existence.
 4. Step one component back in Win32 path, get 'C:\cygwin64\usr'.
 5. Proceed with conversion from the point remembered in (1), the part of path is already converted and checked, we don't need to re-convert it.
 But this approach would really require total overhaul of all the path handling which is difficult.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

Problem reports:
Unsubscribe info:

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