2

I'm using OS X 10.10.5, and I'm seeing a strange issue with hardlinked files. When I update one of the linked files and save the change, the other linked file becomes blank -- a zero-byte file. This happens when either linked file is updated. On investigation, it appears that the inode of the saved file is changing, i.e. before saving, both files have an inode 1777192, and after saving the updated file has an inode 1777268, while the linked file is still 1777192.

Is this normal behavior for OS X? What can I do to maintain the link when updating the files? I use hardlinks to keep certain files in a folder I rsync to an external server, so I need to be able to update these and maintain the link. Symlinks break when they're overwritten, so I can't use them for this purpose.

If it's relevant, this computer has a networked account on a campus network.

Edit: The file in question is a .bib file, and the behavior occurs when I edit and save it with TeXShop. I tested with vim and found that this does not reproduce the failure. However, the error is reproduced with the built-in TextEdit app.

Improve this question
3
  • 2
    You should add how you're "saving" the file. I don't think this behavior is built into OS X, so it's probably related to the tool/method you're using.
    – jimtut
    Jul 26, 2016 at 18:30
  • Edited to show tests with vim, TeXShop, and TextEdit, with only the latter two reproducing the behavior.
    – soldrinero
    Jul 26, 2016 at 22:05
  • 1
    Some editors "update" a given file by writing to a temporary file, removing (unlinking) the original and then moving (renaming) the temporary file to the original name. Compare this question. This explains why inode numbers get different, nothing unusual here. However I don't understand why and how the original file is truncated to zero before unlinking. Setting the file as read-only should prevent truncating this particular file (I mean particular inode, not name), while abilities to create a file, to remove or to move depend on directory permissions.
    – Kamil Maciorowski
    Jun 18, 2017 at 21:07

1 Answer 1

Reset to default
0

I have just started learning about linux commands and came across the same error. Here is what I did

  1. Created a file test.rtf
  2. ln test.rtf hardLinkedTest.rtf
  3. ln -s test.rtf softLinkedTest.rtf

When I edited hardLinkedTest.rtf there was no impact on the test.rtf while the changes reflected when I edited softLinkedTest.rtf.

What I found is that the hard linked file is written to a temporary staging area which replaces the original file. So the link created for the two files is broken. This is clear as inode number for both files is different. Looks like MacOS crippled the ln command somehow.

There are still grey areas around this and I am looking for more details.

Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .