2

I've a file in a folder and I don't know anything about this file (how it's generated and updated) because it comes from an application running on my system of which I don't have the source code.

The file format is clearly json and I successfully created an hard link to it (using the shell command ln file hardLinkToFile) and placed it on another directory.
At this point I check the "2" files and they are exactly the same as expected, but when I perform an action in the application that cause an update of the original file the hard link doesn't get updated.

Any idea on how I can solve this problem?

UPDATE: As pointed out by both Vlad Lazarenko and mvds the file probably get deleted and a new one is created, is there something I can do to obtain a solution equivalent to the hard-link one I thought initially about?

Francesco
  • 1,047
  • 11
  • 26
  • 1
    use a symbolic link. The application apparently removes the file and creates a new one. Check the link count of your file, using `stat -f %l filename`, before and after starting this application. – mvds Feb 15 '12 at 17:58

4 Answers4

3

If a hard link is not getting updated, it means that application is removing the old file and creates a new one. Thus, you still have a hard copy of the previous file, but new file has a totally different inode, though path is still the same. You can verify it simply by changing the content of that file yourself - the link should get updated.

  • I've updated the answer, think you're right (I thought the same initially and asked here for confirmation)... now I'm looking for a work-around for this strange behavior – Francesco Feb 15 '12 at 18:04
1

@Vlad and Francesco. It's really in this way. I verified that vi leaves the inode unchanged and the src and dest file are both changed, while e.g. the kate editor doesn't and I was getting mad to understand why the changes I made in the src file weren't also in the dest file. You can easily check this with the command ls -li srcfile destfile before editing one of them with each editor I mentioned. By the way it's not nice that the hard link are application dependent

Manticore
  • 309
  • 2
  • 13
  • "it's not nice that the hard link are application dependent" - amen. – dave Apr 01 '17 at 03:02
  • It is not nice because the file systems failed and are still at 1970s API level. There is a good reason for kate doing it because a crash in the middle of a write would lose data. File content and identity should be separated but it isn't. Thats the main reason why hardlinks are almost everywhere unused. Unfortunately Unix guys are the most braindead and wont invent a swap content atomically, you can just swap the inode number via common Unix API. – Lothar Feb 14 '20 at 10:13
1

I am getting the same behavior in TextEdit, but not in TextMate. I would suspect this is due to the revision control built in to OS X Lions document architecture. TextEdit uses versioning, while TextMate does not. Most likely this function replaces the file instead of changing it, as described by @Vlad Lazarenko.

Simon
  • 3,667
  • 1
  • 35
  • 49
  • I don't think this is about revision control, I'm not working on these files directly, they are generated (not directly) by another application – Francesco Feb 15 '12 at 18:05
  • for me it works with sublime text but not with text edit – Nav Sep 23 '15 at 16:58
0

I guess it is a bit too late... Anyways, accidentally I found that, if you change the default app for the file, the hard link gets separated from original file. Even if you click on change all and do not relate to that specific file.

dgrigonis
  • 387
  • 5
  • 10