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?

  • How do you edit it? – mmmmmm 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. – Mark A. Donohoe 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

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.

  • 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! – Mark A. Donohoe 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! – Mark A. Donohoe 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. – Mark A. Donohoe Jun 28 '11 at 5:08

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.)

  • 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. – Mark A. Donohoe Jun 25 '11 at 11:27
  • it's not just TextEdit, but all Cocoa-based applications that use the document architecture, which most do. – Mark A. Donohoe Jun 26 '11 at 11:42

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

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.