Community
Participate
Working Groups
To reproduce: 1. Create a simple project File > New > Project... > General > Project 2. cd to to project directory in a terminal window and create a dangling symbolic link: ln -s nonexisting dangling 3. Refresh the project. 4. Try to rename the project. A dialog pops up saying: "Resource 'project_name' is out of sync with file system." There is an inconsistency between initial population of the resource tree and the way resources are checked for existence later on. The children of a folder are determined by calling LocalFile.childInfos(EFS.NONE, NULL) inside UnifiedTree.getLocalList(UnifiedTreeNode). LocalFile.childInfos returns children based on java.io.File.list() method that returns all files including dangling symbolic links. When the resource tree is synchronized with file system later, Resource.isLocal method is called, which returns false for dangling symbolic links.
A proposed fix is pushed to Gerrit: https://git.eclipse.org/r/#/c/6086/
There is some history behind this that I should explain. In the past we did exactly this - broken symbolic links were omitted from the resource tree entirely. But consider this case: - A group of people sharing a project through version control - The project contains symbolic links. On some team members machines these resolve to valid locations, but for other team members they do not. They are happy to be in this state.. maybe the team member that doesn't have that link target location isn't using that particular library/resource/etc. - In this case the resource is created via a call from the version control system, so changes at the level of RefreshLocal don't initially help. - If we "delete" the resource on the next refresh local, as in your patch, then it will appear as an outgoing deletion to the SCM. The person who gets this doesn't want to push this change because it is a valid link for other people on the team. So they are stuck with always having outgoing deletion they need to ignore. Based on this scenario I believe we have tried a tricky balancing act where we want the dead link to appear in the resource tree, but generally ignore it. This is similar to the OS-level or shell behaviour, where the link will still show up, but attempting to modify it will correctly fail. It looks we don't handle the project rename case, so maybe there is a way to fix that. See for example bug 289637 that fixed the move case.
(In reply to comment #2) Pushed new patch to https://git.eclipse.org/r/#/c/6086/. This patch preserves representation of dangling symbolic links in resource tree and modifies the synchronization checking algorithm to not report false file system changes for the dangling symbolic links.
Reviewing it now.
Pushed to master: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=9024a36882b5e2662d28e96422544acbb9200279 Szymon, I don't know what to do with the gerrit change. I didn't want to apply it because it is based on an old snapshot of master. I cherry-picked Sergey's change into master and reviewed/tested/released. Thanks for the fix Sergey, and sorry for the very slow response.
(In reply to comment #5) > Szymon, I don't know what to do with the gerrit change. I didn't want to > apply it because it is based on an old snapshot of master. I cherry-picked > Sergey's change into master and reviewed/tested/released. That's fine too.
