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, 2011 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. Jun 25, 2011 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, 2011 at 11:20
  • 2
    Consider editing your question, given that your assumptions were wrong.
    – Daniel Beck
    Jun 25, 2011 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, 2011 at 11:29

3 Answers 3


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! Jun 25, 2011 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, 2011 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! Jun 26, 2011 at 11:37
  • @MarqueIV: symlinks might work. Jun 26, 2011 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. Jun 28, 2011 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. Jun 25, 2011 at 11:27
  • it's not just TextEdit, but all Cocoa-based applications that use the document architecture, which most do. Jun 26, 2011 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

You must log in to answer this question.

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