Jeff King <peff@xxxxxxxx> writes:
> But wouldn't we still fail writing "foo/bar" at that point if "foo" is a
> regular file (again, we should never do this, but that is the point of
> the test).
The point of the test is not to create foo, whether it is a symlink
or an emulating regular file, in the first place.
In this piece:
>> +test_expect_failure 'symlink escape via ..' '
>> + {
>> + mkpatch_symlink tmp .. &&
This is a patch to create "tmp" that points at ".."
>> + mkpatch_add tmp/foo ../foo
And this is a patch to create "tmp/foo", and make sure ../foo does
not exist in the filesystem to prepare for the test.
>> + } >patch &&
>> + test_must_fail git apply patch &&
And this patch, if the rejection logic were to be broken in the
future, might create "tmp" and then try to follow it to affect
"../foo".
>> + test_path_is_missing ../foo
So if this test makes sure if "tmp" is missing, then it would be
alright, no? The "follow the symlink to affect ../foo" may not
happen on a filesystem without symlinks, but verifying that "tmp"
is missing will assure us that the patch application is atomic,
i.e. if we see "tmp" on the filesystem after seeing "git apply"
failed, that is a sign that "git apply" failed to be atomic.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html