Community
Participate
Working Groups
Build ID: HEAD as of 3/21/2007 When one deletes a folder keeping history (e.g., using the Package Explorer), Eclipse moves each file inside it to the local history zone, even if it is a symlink. Moving a relative symlink breaks it, leaving an unusable history entry, while moving an absolute symlink leaves a history entry that tracks the target file instead of storing a snapshot of the data at the time of deletion. I'm not sure whether deleting a symlink to a file should save the target file's data in the local history zone (deleting an Eclipse linked resource doesn't), but it certainly shouldn't put a symlink there. Steps To Reproduce: 1. Start Eclipse in a new workspace; let $WORKSPACE be its path. 2. In the Package Explorer, create a new "Project" named "proj". 3. In a shell: cd $WORKSPACE/proj echo bar >bar mkdir dir cd dir echo foo >foo ln -s ../bar bar 4. In Eclipse: Select "proj" in the Package Explorer and press F5 to refresh. 5. Select "dir", press Delete, and select Yes. 6. Right-click "proj" -> Restore From Local History. Note that "dir/foo" has a history entry but "dir/bar" does not. 7. In a shell: cd $WORKSPACE/.metadata/.plugins/org.eclipse.core.resources/.history find . -ls Note the symbolic link. I got this output: 1947569 0 drwx------ 4 matt matt 96 Mar 21 20:25 . 1947572 0 drwx------ 2 matt matt 96 Mar 21 20:25 ./e6 1947565 0 lrwxrwxrwx 1 matt matt 6 Mar 21 20:25 ./e6/80eb50d20bd8001b1273a26d6a37b67a -> ../bar 1947583 0 drwx------ 2 matt matt 96 Mar 21 20:25 ./bc 1947564 4 -rw------- 1 matt matt 4 Mar 21 20:25 ./bc/90f455d20bd8001b1273a26d6a37b67a
Created attachment 61894 [details] Fix by copying data to local history, plus regression test This patch makes DeleteVisitor.recursiveKeepHistory check whether each file has EFS.ATTRIBUTE_SYMLINK. If so, it still keeps the history but tells IHistoryStore.addState to copy the target contents instead of moving the symlink. There's also a regression test that makes sure there is one history state at the location where the symlink was. (Without the patch, the history state is discarded as unusable because the "data" is a broken symlink.) This patch aligns the behavior of deletion of a folder containing a symlink to a file with the behavior of deletion of just the symlink: history is kept for the target contents. Alternatively, one could argue that Eclipse should skip keeping history in both cases to align symlinks with Eclipse linked resources. If so, the regression test for this bug would run "find $WORKSPACE/.metadata/.plugins/org.eclipse.core.resources/.history -type l" and complain if any symlinks are found.
Assigning to myself to review patch
Consider for RC1.
Matt, isn't this a duplicate of bug 174492?
As originally stated, this bug is distinct from bug 174492. However, I realize now that your modification of my fix for bug 174492 had the side effect of also fixing this bug. There's still an inconsistency: deleting a symlink to a file by itself keeps history, but deleting it as part of a larger recursive deletion doesn't. It might be good to remove the inconsistency by modifying ResourceTree#internalDeleteFile to not keep history for a symlink to a file deleted by itself.
Since the original issue was fixed as per comment 5, I would suggest marking this FIXED. Matt are you still interested in the "little inconsistency" such that you'd find it worthwile filing a new bug for it?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
