#139: Existing symbolic links not deleted ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ I had a case where a git repository did not exist any more, but the symbolic links pointing into the git repository were still there. GetComponents then checked out the repository, and then got confused -- it created links inside the repository (which it is not supposed to modify!) pointing nowhere.
I think ln should be called as "ln -nsf", or the link (if it exists) should be deleted before the new link is created.
#139: Existing symbolic links not deleted ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------
Comment (by anonymous):
I didn't test this, but I don't like the -n option so much. Imagine the base Cactus source tree residing within a symlink - that is not unusual, at least not for me. Now GetComponents might try to create a symlink to some repository directly within that directory - which is a symlink - and overwrites the symlink to the whole Cactus checkout.
For reference: "-n: treat destination that is a symlink to a directory as if it were a normal file"
We could use the -n option if we can be sure that the destination is always the real destination, e.g. instead of (I didn't check if it is doing this): ln -fs path/source . it could execute ln -nfs path/source ./source
#139: Existing symbolic links not deleted ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------
Comment (by eschnett):
The "destination" is the symlink that is to be created. Since GetComponents never tries to create a symlink for the Cactus directory itself, this is not an issue. Creating a symlink inside a symlink works fine with the "-n" option; the only difference it makes is if the destination already exists. The destination is not the directory that will contain the symlink, but the symlink itself that is to be created.
#139: Existing symbolic links not deleted ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------
Comment (by knarf):
That was my point. Imagine a Cactus checkout in /work/user/Cactus and you have a symlink: /home/user/Cactus -> /work/user/Cactus. Now you let GetComponents work in /home/user and update a git repository within it which should link into /home/user/Cactus/example -> /home/user/Cactus/repos/example.
It could do that with two commands: a) ln -fs /home/user/Cactus/repos/example /home/user/Cactus b) ln -fs /home/user/Cactus/repos/example /home/user/Cactus/example
Both result in the same link within 'Cactus' in case there is no 'example' there yet. Adding -n to version a) would, however, result in overwriting 'Cactus'. The question now is which version of the ln command is actually used by GetComponents. Version b) would however fail without -n if 'example' already exists, because it would try to create an 'example' link within the target of the existing 'example' link.
#139: Existing symbolic links not deleted ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------
Comment (by knarf):
Replying to [comment:3 knarf]:
Both result in the same link within 'Cactus' in case there is no
'example' there yet. Adding -n to version a) would, however, result in overwriting 'Cactus'. The question now is which version of the ln command is actually used by GetComponents. Version b) would however fail without -n if 'example' already exists, because it would try to create an 'example' link within the target of the existing 'example' link.
As a summary: using -nfs is probably the best option, but one has to make sure that the name of the target link is always specified in the link command, not only the directory of the link target like in version a) above.
#139: Existing symbolic links not deleted ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: accepted Priority: major | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+----------------------------------------------- Changes (by eric9):
* status: new => accepted
Comment:
GetComponents should always provide an explicit link as in case b). I'll double check, but it sounds like we can add the -nf options without issue.
#139: Existing symbolic links not deleted ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: closed Priority: major | Milestone: Component: GetComponents | Version: Resolution: fixed | Keywords: ----------------------------+----------------------------------------------- Changes (by eric9):
* status: accepted => closed * resolution: => fixed
Comment:
"ln -s" is now "ln -nsf". I tried to recreate erik's scenario in the original comment and GetComponents handles this situation correctly, so I'm closing the ticket.
trac@lists.einsteintoolkit.org
-
Einstein Toolkit