I have two computers (both MacBook Airs) for which I sync one directory tree in both, but not the entire hard drive or any other directories.

Let's say on computer A the directory is /Users/aellett/projects

Let's say on computer B the directory is /Users/bellett/projects

Generally, I'll log into computer B and then remotely connect to computer A as user 'aellett'. As super user I sync the two project directories as follows:

rsync -av /Volumes/aellett/projects/ /Users/bellett/projects/

and this works as expected.

On both computers I have another file letter.txt in a different directory which is not getting synced.

Let's say on computer A the file is found in /Users/aellett/letters

On computer B the file is found in /Users/bellett/correspondence

Generally, I don't want to share what's not included in /Users/<username>/projects. But I do want to share this particular file.

So on both computer I made a correspondence directory in projects. And then I made hard links as follows

On computer A:

ln /Users/aellett/letters/letter.txt   /Users/aellett/projects/correspondence/letter.txt

On computer B:

ln /Users/bellett/correspondence/letter.txt   /Users/aellett/projects/correspondence/letter.txt

The next time I synced the two computers I did the following

rsync -av -H /Volumes/aellett/projects/ /Users/bellett/projects/

When I checked on computer B, /Users/bellett/projects/correspondence/letter.txt was correctly synced. But, the hardlink to /Users/bellett/correspondence/letter.txt was no longer there. In other words, /Users/bellett/projects/correspondence/letter.txt was identical to /Users/aellett/projects/correspondence/letter.txt but it differed from /Users/bellett/correspondence/letter.txt. Since these two files were hard linked on both computers, I expected them to still have the hard link.

Why are my hard links not being preserved?


I'm not sure I can explain this better than rsync's man page does:

-H, --hard-links This tells rsync to look for hard-linked files in the transfer and link together the corresponding files on the receiving side. Without this option, hard-linked files in the transfer are treated as though they were separate files.

When you are updating a non-empty destination, this option only ensures that files that are hard-linked together on the source are hard-linked together on the destination. It does NOT currently endeavor to break already existing hard links on the destination that do not exist between the source files. Note, however, that if one or more extra-linked files have content changes, they will become unlinked when updated (assuming you are not using the --inplace option).

Note that rsync can only detect hard links between files that are inside the transfer set. If rsync updates a file that has extra hard-link connections to files outside the transfer, that linkage will be broken. If you are tempted to use the --inplace option to avoid this breakage, be very careful that you know how your files are being updated so that you are certain that no unintended changes happen due to lingering hard links (and see the --inplace option for more caveats).

Note that -a does not imply -H, and even if you add -H the other side of the link is not part of the same transfer (and can't be, because the surrounding directory structure is different) rsync doesn't see both sides of the link at the same time, and hence cannot update the linked file in both locations. That is, when it updates /Users/bellett/projects/correspondence/letter.txt, it can tell it's linked to something else (by the link count), but has no idea where that link exists. --inplace may solve the problem, but it also may cause other problems; see its section of the man page.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.