Hi Fedin, On Jun 11 17:08, Fedin Pavel wrote: > Hello! > > Some time ago i reported ability to access things like > "/usr/nonexistent/..bin". I still had this problem and i tried my hands on > fixing it. > The patch works by checking the actual existence of the path before > removing the last component from it. For performance reasons, only one check > is done for things like "../..". Because, obviously, if "/foo/bar/baz" > exists, then "/foo/bar" exists too. Also, the check is done only after some > components have been added to the path. So, for example, current directory > (obtained when processing relative paths), will not be checked. > I tried to add a similar test also to normalize_win32_path() function, > however this broke things like "cd /usr/src/..". For some reason, a POSIX > version of the path (but with reversed slashes) is passed to this routine > when expanding mount points, so, consequently, test for "\usr\src" using > GetFileType() fails. > I think it's ok, at least POSIX paths now behave in POSIX way. I have > tested against performance, there is some loss (~0.2 seconds), but only for > referencing '..'. > With this patch i am able to compile the latest version of glibc with no > problems.
I applied your patch with a little stretch of imagination as falling under the trivial patch rule, which doesn't require a copyright assignment. I only tweaked it slightly since I found that moving the setting of check_parent has a tiny performance advantage. Cgf and I talked privately about this patch and we're both happy you found such a simple solution to fix a long-standing problem. Sometimes, when you're working long enough on some code, you just miss to see the wood for the trees. Andrew, can you please polish one of the goldstar's in your vault and give it to Fedin? Btw., Fedin, even if I let this go in under the trivial patch rule, it would be very nice if you could fill out the Cygwin copyright assignment form http://cygwin.com/assign.txt and send it to the given address. This allows you to provide any length of patch in future. Thanks again, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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