Tell me more ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.
up vote 6 down vote favorite

Ok, this has me banging my head. In OS X, to create a hard link, in a terminal window, you're supposed to be able to just type this...

ln a.txt b.txt

...and this should create a hard link from a.txt to b.txt. Simple and straight forward.

When I execute that statement, sure enough, in Finder b.txt appears right alongside a.txt. However, even after editing a.txt using TextEdit, b.txt still has the original data! In other words, it looks like it performed a copy, not a link, hard or otherwise.

Makes no damn sense to me! So can someone tell me what I'm doing wrong here?

share|improve this question
How do you edit it? – Mark Jun 25 '11 at 11:12
I just open the file in TextEdit and add some text. I just cut and copied a block over and over and over. In Finder, 'A.txt' now has a different size than 'b.txt' meaning they are in fact pointing to two different (data)files on the disk. – MarqueIV Jun 25 '11 at 11:14
Curious. I just tried this using vi to edit the files and the link persisted. With TextEdit, as you observe, it breaks. – borrible Jun 25 '11 at 11:20
2  
Consider editing your question, given that your assumptions were wrong. – Daniel Beck♦ Jun 25 '11 at 15:11
The answers clearly show that the hard-links are, in fact, working; the title suggests otherwise. It's just the file-replacing behavior of OS X applications that gets rid of your hard links, which is a whole different issue. – Daniel Beck♦ Jun 26 '11 at 11:29
show 3 more comments

migrated from stackoverflow.com Jun 25 '11 at 11:55

3 Answers

up vote 14 down vote accepted

The reason for this behavior is rather straightforward, and it relates to how files are saved in most Mac OS X applications: Atomically.

What happens is that a copy of the file is written to a temporary staging area, and then moved to replace the original file.

This, quite naturally, breaks hard links.

share|improve this answer
Yeah... seems to be any OS X apps that uses Cocoa's document-based approach. That really stinks! I'm gonna see if I can get away with using soft-links (aliases) instead. Not sure though because I'm editing a DefaultKeyBinding.dict that the system uses. Hopefully it's smart enough to follow the link. We'll see! – MarqueIV Jun 25 '11 at 11:30
So true. This is also why editing Unix-y system configuration files is a pain in OS X GUI editors and much easier to accomplish in vi — it isn't enough to set write permissions on the file, you also need the folder! – Daniel Beck♦ Jun 25 '11 at 11:56
BTW, soft-links dodn't work, so I guess I'm back to scripting file copies after a save to all the places I need this. Stinx! – MarqueIV Jun 26 '11 at 11:37
@MarqueIV: symlinks might work. – Williham Totland Jun 26 '11 at 19:34
that's what I meant. Got the term wrong. Specifically it's for OS X's key bindings. It expects the actual file to be in a specific location and doesn't work with symlinks. It does however work with hard links, however as stated, since the editor is Cocoa-document-based, I can't edit the file without breaking the links, so it looks like I have to resort to manually copying (or re-setting up the hard links) after I edit the document. Not optimal, but nothing a quick script won't fix. – MarqueIV Jun 28 '11 at 5:08
up vote 3 down vote

If appears, see this entry from superuser, that this is a feature of TextEdit. So, the normal method for creating hard links is correct, but TextEdit behaves in such a way as to break this. (The link says that it creates a new file and then moves it over the old file after editing.)

share|improve this answer
Yeah... just saw that on SU right as you posted this. It's not just TextEdit either. It seems to be all document-based apps. Stinks because this means I can't use document-based tools to edit hard linked files. – MarqueIV Jun 25 '11 at 11:27
it's not just TextEdit, but all Cocoa-based applications that use the document architecture, which most do. – MarqueIV Jun 26 '11 at 11:42
up vote 1 down vote

Note that emacs also exhibits this (startling!) behavior by default (in all unixes), thought the cause is slightly different (it is the "safe" thing to do in very low disk space situations). However, it can be configured in several ways.

See the documentation for make-backup-files (use C-h v make-backup-files) and for

  • backup-by-coping
  • backup-by-coping-when-linked
  • backup-by-coping-when-mismatch
  • backup-by-coping-when-privileged-mismatch
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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