• [6.9.2] Mover does not move symlink files targeting non-existent files


    bland328
    • Minor

    Problem description

    Under Unraid 6.9.2, mover appears to leave symbolic link files targeting non-existent files ("broken" symlink files) in the cache forever.

     

    Though such symlinks are commonly called "broken" or "invalid" symlinks, those titles are a bit misleading; in truth, though they "feel" weird, they are perfectly legitimate file system objects with a variety of purposes and reasons for existing, so I hope/assume this is simply a bug and/or oversight in mover.

     

    How to reproduce

    Simply make a symlink to an invalid path in a user share that uses the cache, like this...

    # ln -s /foo/bar /mnt/user/test/symlink

    ...then start the mover, and check to see if the symlink file has been moved to the array.

     

    Notes

    1. I see this both on a mature production server and on a newer box that still has a close-to-vanilla configuration; the attached diagnostics are from the latter.
    2. Before capturing diagnostics, I turned mover logging on and started mover to test against a /mnt/user/test/test_symlink file.
    3. I see "/mnt/cache/test/test_symlink No such file or directory" appears in the syslog, which may be a clue as to the bug causing this: broken symlink files are peculiar in that some methods of testing for existence fail because the symlink's target file doesn't exist (because the symlink is being "followed"). Here's an example of what I mean, in hopes it helps:

     

    root@Tower:/mnt/user/test# ls -la test_symlink
    lrwxrwxrwx 1 root root 18 Apr 28 08:21 test_symlink -> /invalid/test/path
    root@Tower:/mnt/user/test# [[ -e test_symlink ]] && echo "exists" || echo "does not exist"
    does not exist
    root@Tower:/mnt/user/test# [[ -L test_symlink ]] && echo "exists" || echo "does not exist"
    exists

     

    protekto-diagnostics-20210428-1027.zip



    User Feedback

    Recommended Comments

    I'm unsure on the right priority for this--it is certainly not an Urgent data-loss emergency, but also seems more than Minor, as it can be a significant problem for those relative few unlucky enough to run into it.

    Link to comment
    Share on other sites


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.