This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [PATCH] Check for existence of the path before processing '..'
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 11 Jun 2013 17:26:24 +0200
- Subject: Re: [PATCH] Check for existence of the path before processing '..'
- References: <001401ce66a4$bb9029a0$32b07ce0$%fedin at samsung dot com> <20130611142002 dot GA1927 at ednor dot casa dot cgf dot cx> <20130611150446 dot GB9484 at calimero dot vinschen dot de> <20130611151708 dot GB2235 at ednor dot casa dot cgf dot cx>
- Reply-to: cygwin at cygwin dot com
On Jun 11 11:17, Christopher Faylor wrote:
> On Tue, Jun 11, 2013 at 05:04:46PM +0200, Corinna Vinschen wrote:
> >I don't see how do this without calling path_conv, though. You have to
> >perform the full conversion on the parent path, with symlinks and
> >everything to get the right result.
>
> Yes, but it is a HUGE stack hit to call path_conv recursively here.
Shouldn't that be much reduced by the fact that the temporary buffers
used by path_conv are tmp_pathbuf buffers? Originally, when we started
with 1.7, we had all those 64K buffers on the stack and thus a lot of
spurious crashes due to stack overflow. But since using tmp_pathbuf
buffers we got rid of those.
Maybe we should contemplate the idea to raise the maximum number of
tmp_pathbuf buffers to accommodate situations we're not aware of at
this point in time.
> >However, I'm rather impressed by the low impact of this change. I moved
> >the check_parent setting so it's only set when a slash occurs, and then
> >I made a couple of runs building coreutils. As you know, GCC uses ..
> >paths a lot. The performance hit is almost unnoticable: 72.3 seconds
> >without, 73.4 seconds with the patch.
>
> If we are considering doing this, then couldn't we somehow just avoid
> eliminating "/.." until after the path is fully parsed and then collapse
> all of them in one final loop? Also, don't we have the same problem for
> foo/./bar? We change that to foo/bar but foo may not exist.
The problem with .. is that a path component disappears while normalizing
the path, without checking it's existence. Therefore foo/./bar is no
problem here, because the final patch still contains foo and thus it's
existence will be checked anyway.
I may be missing something, but if we don't remove .. and . from the
path right at the start of path_conv, then we have exactly the problem
which so far kept us from doing the check: A . or .. component spoils
the mount_table->conv_to_win32_path path, and it might (I'm *not* sure)
break the sym.check call as well.
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