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

Jeff King [off-list ref] 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.