Re: [PATCH] apply: refuse touching a file beyond symlink

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 30, 2015, 21:50 UTC
Message-ID: <xmqqd25waqf9.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150130204805.GA10616@peff.net>

Jeff King <peff@peff.net> writes:

> But could we instead pull this check to just before the write-out time?
> That is, to let any horrible thing happen in-core, as long as what we
> write out to the index and the filesystem is sane?

The check in-core is somewhat tricky, because we would need to (1) catch a patch that creates a symlink and also a file as if that new symlink is a directory and (2) allow a patch that removes a symlink and also a file in a new directory at the location removed symlink used to occupy.

For (1) we need to see if there is a patch in the entire input that creates a symbolic link and reject the input. For (2) we need to see if there is a patch that removes the symbolic link. (1) cannot be caught with the approach based on fn_table[], which is inherently meant to help incremental application, that is oblivious to a path that will materialize after applying a later patch in the input.

Let me think about it a bit more. The fix probably needs to abandon depending on fn_table[] stuff, if we want to do in the "sanity check the input and compute the final state all in-core" route.