|JGit DirCacheCheckout badly remove symlinks [message #776847]
||Mon, 09 January 2012 06:26
| Cedric Darloy
Registered: January 2012
Using DirCacheCheckout in Jgit, I encountered this issue:
My repository working tree (/home/user/git/repo) in under a symlink :
ls /home/user :
lrwxrwxrwx git -> git1
When using DirCacheCheckout.checkout() and when a file is removed,
the symlink git is deleted.
Looking through sources, it seems that the DirCacheCheckout.removeEmptyParents is responsible :
When iterating in removed files in checkout(),
it compares prefixes at first removed file (e.g /home/user/git/repo/test/test.txt) to blank path ""
Seems it detects prefix is not the same, removeEmptyParents is called on file
/home/user/git/repo (the working tree)
The removeEmptyParents then compares its parent /home/user/git to working tree
/home/user/git/repo and since it is not the same calls
But since /home/user/git is a link, it is deleted despite not empty.
A simple update would be to verify before deleting a directory that it is actually empty to not delete symbolic links:
if (parentFile.list().length == 0 && !parentFile.delete())
|Re: JGit DirCacheCheckout badly remove symlinks [message #776910 is a reply to message #776847]
||Mon, 09 January 2012 09:06
| Christian Halstrick
Registered: July 2009
I am sure you found a bug but I am having trouble reproducing.|
Let's differentiate between two cases:
1) Symbolic links which are inside the working tree (see http://stackoverflow.com/questions/954560/what-does-git-do-to-files-that-are-a-symbolic-link)
2) Symbolic links on top of the working tree
I think you have case 2). The problem you describe is worse then you describe. JGit tries to delete a folder which is outside of the working tree. This should never happen. The fix you suggest only fixes the cause - but we should find why at all we are trying to delete the folder on top of the working tree.
I think the bug is there since ages but he normally causes no harm. That is because the folder on top of the working tree is normally not deletable because it's not empty. In your special case the folder on top of the working tree is a symbolic link, therefore deletable.
The problem is in line 429 of DirCacheCheckout.java where we call removeEmptyParents(..., llast) without checking that 'last' contains something meaningful.
Thanks for finding this. I'll propose a fix and keep you up to date.
Powered by FUDForum
. Page generated in 0.01523 seconds