Community
Participate
Working Groups
Because of the weird project structure used at my workplace (a separate repository for each version), I have my file system set up as follows: ~/code/stable/project/subprojects ~/code/release-x.x/project/subprojects I have my workspace pointed to a symlink at ~/workspace/project, with individual eclipse projects pointed to ~/workspace/project/subproject. In this way, if I need to change the working dir from 'project' to 'release-x.x', I update the symlink to point to the desired location, but maintain all of my workspace info, such as the current view and all run/debug configurations. Overall, this seems to work perfectly, except that I cannot use any refactoring that requires renaming a file. This applies to ctrl+shift+r to "rename type" (if that operation would rename the file), and right clicking on the file in the navigator and hitting "rename...". The error I get is "An exception has been caught while processing the refactoring "Rename Type". Reason: {new filename}.java [in {project}] does not exist. This works fine without the symlink, so I'm assuming it's related to that.
Sounds like your workspace is not refreshed after you change the file system contents behind the scenes. You probably want to enable Preferences > General > Workspace > Refresh using native hooks or polling. Or you have to refresh the affected projects manually (or clear the selection in the Package Explorer and refresh the whole workspace).
I have the native hooks or polling pref turned on (this workspace setup is nearly unusable without it). Cleaning and refreshing doesn't fix it. Also, the error always happens, even if I haven't modified the symlinks since I opened Eclipse. The fact that it is a symlink at all seems to be what is causing the problem.
Probably caused by bug 338010.
Would that bug also be the reason that importing a new project that is in a symlink dir results in a project that points to the resolved path of the symlink, not the symlink itself?
Nevermind, the answer is yes. That is bug 233019. Sorry, should've looked first.
*** This bug has been marked as a duplicate of bug 233019 ***
