IntelliJ kills symlinks ?
I was experimenting with symlinks to share code between 2 projects (sounds like a bad idea, but everything else failed ... and don't say: use artifacts!).
It looked promising until I deleted / renamed a file within the linked directory: suddenly the complete folder was gone and I had to reset the symlink.
Is this expected behaviour? I mean everything else seemd to work great.
PS: Running on Win7 64bit and IntelliJ 116.32
Cheers
Please sign in to leave a comment.
By the way: I was using mklink /J (“Directory Junction”)
At the moment IDEA doesn't support junctions at all, and symlinks are supported to a some extent only if you're running IDEA on Java 7.
Windows junctions have always been twitchy - we used to use them in our projects and stopped. Deleting the symlink resulted in deleting the source directory, and scripting to break the link wasn't always successful - we had to write a lot of logic to ensure the link was truly dropped, and then make sure it was there when it was supposed to have been created.
Doesn't help, but you're not the only one who's had problems.
Well I stumpled upon a bug report: IDEA breaks file hardlinks on file save.
After setting the "Safe Write" option to false it seems to work. It's just that this seems to be the easiest option for me, since git submodules are not yet supported.
How did you then share code between projects? Or wasn't that the goal?
The option is only a partial solution as it won't prevent recursive deletion of entire file tree instead of just junction.
We used symlinks to link our jsp dirs with deployed code - was pretty nice, just edit the JSP in your IDE and presto, it's there in the deployed server code. I'm using JRebel now, which is even better, as I can edit the classes and all other resources and not have to redeploy or restart.
We used to use Subversion externals for sharing code, but now use Ivy and shared jars to be much more stable and manageable.
This also gives us more control over who's editing what. With snapshots, it's pretty easy to work on the shared bit, then on the bit that uses it.
Hope this helps.
In older versions of windows (i.e. XP), you could not use the standard delete command. You needed a tool/interface that would use an otherwise unexposed "CopyHook handler" to remove the junction. Vista & Win 7 now handle this seamlessly. I've used Link Shell Extension for 7-8 years (including on XP machines) with great success. From it's information page:
Junctions can be deleted by using the Delete commands from Explorer as usual, if Link Shell Extension is installed, because Link Shell Extension implements a so called CopyHook handler, which intercepts Explorers Delete commands, and thus fixes Explorers problems with junctions. Link Shell Extension changes Delete commands from Explorer on Junctions to unlinking Junctions, and not deleting the content within a junction, which seems most logical.
Windows7: With Windows Vista & Windows7 explorer is natively aware of Junctions, and no interception or CopyHook handler is necessary, Explorer simply works out of the box with junctions. This is also the reason why the Delete Junction menue does not show up on Vista and Windows7.
I rarely use a junction internally in a project. I've used them to point to a sample data directory. I can't recall if I've ever used them in the manner the OP refers to. I also use them to point to "current" versions of the JDK and various libraries. I even use one so my maven repo can exist on a larger partition, but I do not have to configure an alternatge repo setting. And I use them to generally keep my hard drive more organized.
For me, renaming a file in IDEA that is within junction works fine (with Link Shell Extension installed; I have never tried it without that installed.) However, deleting a "directory" in IDEA that is actually a junction is problematic. It does not delete the target directory, but it does delete all its content. So IDEA must be recursively deleting everything, then it deletes the "directory", which in my case is the junction. From Java, executing File.delete() on a junction deletes just the junction (with the caveats given above). It does so even if the target of the junction, which appears as a directory via File.isDirectory(), has content. Of course, executing File.delete() on a "real" directory (i.e. the target) fails if it has content. A simple fix to this issue in IDEA might be for IDEA to try the File.delete() command on the directory, and only recursively delete its content if the initial delete fails. A failed initial delete would indicating it is a "real" directory and not a junction.
You could create a module for the code the you would like to share. Then you can check out that module from subversion out into both projects.
If you don't want to go the version control way, I believe you can just add the module to both projects I believe (at least, if it is not shared with coworkers using Eclipse). If adding doesn't work, you could try to create a module for each project referring to one shared code directory. That way, you might even get along with opening both projects at the same time. Good luck...