I faced a little strange behavior, while using hard links. From Terminal, I create a text file 1.txt and a hard link "to this file"

nano 1.txt
mkdir dir
ln 1.txt ./dir/

I check the resulting hard link and see that its contents are the same as of the original file.

less ./dir/1.txt

I change the initial file ...

nano 1.txt

... and see, that changes was reflected in hard-link

less ./dir/1.txt

I change content of hard-link (more correct, of course - file, being referenced with hard-link) ...

nano ./dir/1.txt

... and see, that changes are reflected in initial file

less 1.txt

Until now, all going well...

Now, I close Terminal and start playing with created files (1.txt and ./dir/1.txt) from Finder. When I change on this two files with TextEdit, changes are not reflected in another file.

The hard link is now broken. What's going on?

migrated from stackoverflow.com May 9 '10 at 21:50

This question came from our site for professional and enthusiast programmers.


It's not about the GUI, it's specifically about TextEdit's strategy for saving changes: it does not write in place on the existing file, but rather it first writes a new one, and when that's completed it removes the old one and renames the new one to the old one's names. Many editors (programs that conceptually alter a file "in place"), GUI or not, use this strategy for safety purposes (you won't lose both the new and old versions if there's a crash at a very unfortunate moment just when the writing is taking place), but as you noticed it "breaks" hard links.

One example of a non-interactive, non-GUI editor program with this behavior is perl with the -i ("in-place edits") command-line option switch...:

$ touch za.txt
$ ln za.txt zo.txt
$ echo ciao >za.txt
$ cat zo.txt 
$ perl -i -p -e 's/a/b/' zo.txt
$ cat zo.txt
$ cat za.txt

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.