3

I moved my filesystem and symlinks from Ubuntu 14.04 to 16.04 by using FAT32 memory card, which apparently broke those links; stopped using BitTorrentSync. Differential condition is that those links are remnants of my OSX installation because of XSym. I do ls -la $HOME | grep Math for a symlink 

-rw-r--r--  1 masi masi   1067 May 17 21:28 Math

which contents in the text-editor

XSym
0078
48055bd2d9c13568c969e1eb8d6a22ac
/Users/masi/Math/

It should point to /Users/masi/LOREM/Math/ instead. Just correcting manually the PATH does not work, since the link stays death. Gilles' command can be applicable here too:

find /Users/masi/Math/ /
    -lname '/Users/masi/LOREM/Math/*' \ 
    -exec sh -c 'ln -snf "/mnt$(readlink "$0")" "$0"' {} \;

where I am not sure if I got the source and destination in the correct order.

Systems: Ubuntu 14.04, Ubuntu 16.04

Community
  • 1
Léo Léopold Hertz 준영
  • 6,928
  • 2
    That doesn't seem to look like a regular symlink. (Those look like this: lrwxr-xr-x 1 itvirta staff 6 Jun 13 15:39 testlink -> foobar). The text file seems to match a description of how Mac OS X saves symbolic links on DOS/FAT filesystems. I don't think Linux supports those on vfat filesystems, and otherwise you would have real native symlinks. (Unless some desktop environments use special text files as "links" (?)) – ilkkachu Jun 13 '16 at 12:52
  • So, if it's not a real symlink, the usual tools (find -lname and readlink) are not going to find it. Also, I can't tell if you need to change them to regular symlinks or edit in that format. – ilkkachu Jun 13 '16 at 12:57
  • 1
    Why not just add a new link with ln -s Math /users/masi/Mathematics so that all path names starting with /Users/masi/Mathematics automatically resolve by replacing that prefix with /Users/masi/Math ? – Ralph Rönnquist Jun 13 '16 at 19:13
  • @RalphRönnquist Sorry, I changed names for clarity because I got confused myself. So you mean ln -s $HOME/Math/ $HOME/LOREM/Math/ i.e. to create a new symlink. Yes, that is a replacement of an old link with a new one. I have many such links etc Physics, Chemistry, ... in a similar fashion. I am thinking how I could handle it in practice. The manual replacement may be the only way to do it here. It is however not what I would like to have. I would like to have a continuous monitoring about those links, and suggestions for fixes. My systems break often, and they are big. Manual means work. – Léo Léopold Hertz 준영 Jun 13 '16 at 20:02
  • Upgrading from Ubuntu 14.04 to 16.04 wouldn't have broken the symlinks. Also, if you say that your "systems break often" then there's something else at work here. On what type of filesystem are these broken symlinks located? – Chris Davies Jun 13 '16 at 22:52
  • Regarding your example. 1. Is your home directory /Users/masi? You reference $HOME along with absolute paths but nothing explicitly ties one to the other. 2. The file-that-should-be-a-symlink-but-isn't contains /Users/masi/Math/. How do you determine that it should really point to/Users/masi/LOREM/Math/? 3. What determines that a file is supposed to be replaced with a symlink? – Chris Davies Jun 13 '16 at 22:55
  • @roaima 1. Home directory is /Users/masi. 2. It should really point to /Users/masi/Lorem/Math because I know my system and the correposding directory is there. 3. I do not know. Do you? – Léo Léopold Hertz 준영 Jun 14 '16 at 06:10
  • @roaima You can assume simply that I changed the directory structure, which broke the symlink. I mean by that my symlinks break often that I change my directory structure often so they break therefore often. – Léo Léopold Hertz 준영 Jun 14 '16 at 06:11
  • There aren't any symlinks in your question though, broken or otherwise – Chris Davies Jun 14 '16 at 08:06
  • Apparently these XSym files are created by MacOS when trying to create symlinks on a filesystem that isn't capable of storing symlinks, like FAT32: https://books.google.de/books?id=K8vUkpOXhN4C&pg=PA1390&lpg=PA1390&dq=mac+softlink+%22xsym%22&source=bl&ots=OLnlQXVwVw&sig=QJiqdJzY9-2bs2xGczXlEIHs8uQ&hl=de&sa=X&ved=0ahUKEwie6bz2267NAhVHOBQKHfaHBjYQ6AEIKDAB#v=onepage&q=mac%20softlink%20%22xsym%22&f=false – Martin von Wittich Jun 17 '16 at 09:13
  • @MartinvonWittich These files were created on Ubuntu. I think messed up the thing, by moving all my files in FAT32 memory card, and to new Ubuntu system. This way also symlinks broke. Does it help the case? – Léo Léopold Hertz 준영 Jun 18 '16 at 22:06
  • 1
    @Masi I don't think that Ubuntu created these XSym files (or even can create them). Also the destination path from your example (/Users/masi/Math/) wouldn't be a valid destination path on Ubuntu - /Users is MacOS, on Ubuntu it would be /home. – Martin von Wittich Jun 19 '16 at 15:15
  • @MartinvonWittich Ok. Is there any change of correcting those? – Léo Léopold Hertz 준영 Jun 19 '16 at 15:18
  • The two scripts I have (already) given you don't rely on /Users or /home. Have you tried them yet? – Chris Davies Jun 19 '16 at 20:20

2 Answers2

2

Two possible solutions that spring to mind.

1. Iterate across all the directories in LOREM and symlink them to $HOME

cd "$HOME/LOREM"
for item in *
do
    test -d "$item" || continue
    mv -f "$HOME/$item" "$HOME/$item.DELETE_ME_LATER" 2>/dev/null
    ln -s "$HOME/LOREM/$item" "$HOME/$item"
done

# Once you are happy that only the correct files have been replaced
# rm "$HOME"/*.DELETE_ME_LATER

You can prefix the rm and ln with echo (eg echo rm -f "Users/masi/$item") to see the effect of the script before it makes any changes

2. Process the set of existing files and convert them to proper symlinks

This one will need some heuristics (guesswork), because there is nothing concrete that identifies a file-that-should-be-a-symlink.

Something like this might work

for file in *
do
    # Skip files that we have already processed
    [[ $file =~ DELETE_ME_LATER ]] && continue

    # Look for a path-like string in the file
    path=$(grep "^$HOME/" "$file")
    if test -d "$path"
    then
        # It is a directory
        mv -f "$file" "$file.DELETE_ME_LATER"
        ln -s "$HOME/LOREM/$file" "$file"
    fi
done

# Once you are happy that only the correct files have been replaced
# rm *.DELETE_ME_LATER

Again, you can prefix the mv and ln statements with echo to see the effect without applying any changes.

Chris Davies
  • 116,213
  • 16
  • 160
  • 287
  • 1
    @Masi the second script reads the contents of the files as described by you in your question. Stick echo in front of the mv and ln commands and give it whirl. If they don't parse the not-really-symlinks-at-all files get me a real one and I'll see what I can do. – Chris Davies Jun 19 '16 at 20:31
  • @roiama I am trying to understand the severity of those XSym things. I can find matches of them all over my system. XSym probable means also other things too than symlinks. – Léo Léopold Hertz 준영 Jun 19 '16 at 20:56
  • @Masi I've never come across these XSym files before. You described them as symlinks. They're not Unix/Linux symlinks but it seems from other people's comments that they might be something a Mac produces (like Windows "shortcuts", perhaps, which also aren't symlinks). If they're readable files and they're on a filesystem that can use proper symlinks my code is intended to be able to read them and replace them with the equivalent symlinks as per my understanding of your question. – Chris Davies Jun 19 '16 at 21:21
  • Can you give an example of the output of one symlink which your file does, please. – Léo Léopold Hertz 준영 Jun 19 '16 at 21:21
  • 1
    @Masi, put echo in front of the mv and ln commands so that they become no-ops, and run either of the scripts directly on your system. That will give you first-hand results that you can feed back as necessary. I've offered you an answer; please try it. – Chris Davies Jun 19 '16 at 21:26
  • Is echo -e "yourCode" sufficient? Is this for item in * too general? – Léo Léopold Hertz 준영 Jun 19 '16 at 21:30
0

This is not an answer, just amplifying information that's too big for a comment.

Those XSym files are explained (somewhat) here.

The original poster doesn't mention this in the context of the original question, but I'm guessing that Léo's filesystem was on a NAS (or other home networking server), running Samba, accessed from a Mac. Hence the symlinks that are not actually symlinks.

I'm not 100% positive whether it's the macOS version of ln or Samba itself that writes those fake-symlink files; my guess is Samba, but the document linked above isn't clear on that. The long and short of it is they're way of supporting symlinks for Unix clients on SMB/CIFS filesystems.

Kevin E
  • 468