Re: [PATCH v3] Demonstrate bugs when a directory is replaced with a symlink

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 30, 2009, 01:06 UTC
Message-ID: <alpine.LFD.2.01.0907291758030.3161@localhost.localdomain>
In-Reply-To: <alpine.LFD.2.01.0907291656420.3161@localhost.localdomain>

On Wed, 29 Jul 2009, Linus Torvalds wrote:

Show 7 quoted lines

> 
> Hmm... This looks like it should do it.
> 
> It doesn't make the test _pass_ (we don't seem to be creating a/b-2/c/d 
> properly - I haven't checked why yet, but I suspect it is becasue we think 
> it already exists due to the symlinked version lstat'ing fine), but it 
> seems to do the right thing.

Never mind. The patch does what I set out to do, but it's not relevant for the problem.

What happens is:

 - we remove a/b/c/d to make room for the a/b symlink:

	merge_trees ->
	  git_merge_trees ->
	    check_updates ->
	      checkout_entry ->
	        remove_subtree("a/b") ->
	          recursive rm

   This is correct

 - then we create the a/b symlink to a/b2

	merge_trees ->
	  git_merge_trees ->
	    check_updates ->
	      checkout_entry ->
	        write_entry ->
	          symlink

   This is correct

 - Then we remove 'a/b/c/d' again for the 'unmerged_cache()' case:

	merge_trees ->
	  process_entry ->
	    remove_file

   because th eprocess_entry() will decide that the original tree had that 
   "a/b/c/d" file (true) that needs to be removed (false - we already 
   did that as part of creating "a/b").

Annoying.

		Linus