1

I created a hardlink of a file as follows: 

ln /path/to/source/file1 /path/to/target/file2

Using md5sum, the two files are identical. After a while, the source file has been modified by another program. The target file does not get "updated". The md5sums are now different. The files are on the same partition of course, otherwise I could not create a link.

What I'm trying to do is get a copy of the source file into the target folder (which is versioned), so that I have access to the source file elsewhere.

I tried moving the source file to the target folder with a different name and then creating a symlink to it at the source, but the program expecting the file then (somehow) created a file of the name it wanted in the target folder.

Ideas?

SabreWolfy
  • 368
  • 1
  • 2
  • 13

2 Answers2

3

What I guess is that the version control system (which one?) moves/deletes the hard-linked file around and creates a new copy which is no longer hard-linked to the original file.

What does the link count (the first numeric column in the output of ls -l) tell for the original file? If it is 1, the link got lost. If it is 2, you have to find the real 2nd copy, maybe with the find command. To do this, enter the following command: 

find /commonparent_dir -samefile /path/to/original_file

This searchs for files with the same inode as the file /path/to/original_file starting at the common parent directory (i.e. the mount point).

Sven
  • 98,649
  • 14
  • 180
  • 226
  • This problem presents itself even before I execute any versioning on the files. In fact, I've just tested it by hardlinking the source to a file in a folder I just created. Running that code (very useful thanks; I was not familiar with "-samefile") shows that the hardlink is in place. Each file has a link count of 2. I ran a "watch md5sum ..." on the files, and after a minute or so when the source is modified, the sums are different. And now the link count for both files is 1! Someone the hardlink has been broken? – SabreWolfy Jan 17 '11 at 10:48
  • 1
    What kind of operating system and filesystem are involved and what applications. Which application modifies the source and may have a policy of creating a new file and not overwriting the existing. – Koos van den Hout Jan 17 '11 at 11:03
  • Yes, I think this is exactly what is happening. The file is deleted and recreated on each update. Thanks. It was a session file from Firefox under Ubuntu Linux for reference. – SabreWolfy Jan 17 '11 at 11:14
  • Assuming the new file has the same name wouldn't a soft link solve this issue for you? ln -s source target – James Yale Jan 17 '11 at 11:52
  • That does "solve" it in the sense that the file is then (always) available in the target folder. The versioning is then the problem however: the soft link is versioned and then points to the "wrong" location for the source file from another machine. I'm using Bazaar. – SabreWolfy Jan 17 '11 at 13:48
  • Could you just put the original file under bzr control as well? – Sven Jan 17 '11 at 14:28
  • That would mean creating a second repository? At present all files under one folder are versioned, which is my repository. – SabreWolfy Jan 17 '11 at 14:54
0

I can replicate the scenario in a test case, so I presume this is what is happening. If the source file is deleted, the hard link is lost. Even if a new file is created with the same name, the hard link of course is not reinstated. This is what must be happening I think. The program which updates the source file must be deleting the file and recreating it.

SabreWolfy
  • 368
  • 1
  • 2
  • 13