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?
Best Answer
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...: