Existing symbolic links not deleted

Create issue
Issue #139 closed
Erik Schnetter created an issue

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.

Keyword:

Comments (7)

  1. anonymous
    • removed comment

    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

  2. Erik Schnetter reporter
    • removed comment

    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.

  3. Frank Löffler
    • removed comment

    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.

  4. Frank Löffler
    • removed comment

    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.

  5. Eric Seidel
    • changed status to open
    • removed 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.

  6. Eric Seidel
    • changed status to resolved
    • removed 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.

  7. Log in to comment