6

I created a hard link pointing to a file in my dropbox dir - the link was created inside a folder where this file needs to be in order to be accessed by the programs I use to edit it - 

mklink /h path_to_hard_link C:\dropbox\git\repo\existing_file

I started working with the hard link alright. At some point I realized that the changes do not propagate to the file in repo\ - filesize, modification date, nothing - NOT EVEN the contents.

What am I doing wrong ?

EDIT : is it possible to be program dependent ? I mean the editor I use for these files does indeed edit them - but only edits the hard link. The file linked hasn't been modified. Moreover this editor does not seem to be able to follow symbolic links

EDIT2 : according to the article linked by surfasb :

Because a hard link is a directory entry for a file, an application can modify a file by using any of its hard links. Applications that use any other hard link can detect the changes.

Meaning the original file must contain the modifications when opened with an appropriate editor directly - not only via its hard link - right ?

However, directory entries for hard links are updated only when a user accesses a file by using the hard link. For example, if a user opens and modifies a file by using its hard link, and the size of the original file changes, the hard link that is used to access the file also shows the new size.

If I understand this deplorable specimen of english correctly this means that I can have 69 hard links (up to 1023 actually) to the same file showing different sizes for that same file ?!

EDIT 3 : well according to surfasb I do understand this correctly - a limitation of the filesystem. Anyway - strange thing - this is not always the case - sometimes the change in the attributes is immediately visible back to the original file - when there is change - my real concern now is that at least one program I am using does not seem to edit the file linked but only the hard link. Possible ? dir /a does not reveal much about hard links - any way to see them ?

Improve this question
1

2 Answers 2

Reset to default
5

I think the answer is (quoted from some helpful guy) :

What you have to consider is the way an application/program works on a file.

Some edit the file directly, and they should work perfectly fine with hardlinks. Although I didn't knew the "fileinfo difference" problem until now ...

Other applications copy the file and then delete the old one when they save their edited version. This programs obviously break the hard link with that hidden copy operation. What they save is no longer the file they had opened. When they then delete the old version, they remove this single hardlink from the directory. Other hardlinks remain, and so you get two files in the end.

So yes - hardlinks can and will break - which limits their usefulness - badly thought.

correct me if wrong

Improve this answer
1
  • If they copy the file, they also copy the hardlink.
    – surfasb
    Jul 8, 2011 at 0:06
3

Did you turn on the Last Accessed Time setting? It is turned off by default starting with Vista++, due to performance reasons.

I see this question a lot. I always tell people to hit up technet and read the documentations on NTFS.

http://technet.microsoft.com/en-us/library/cc781134(WS.10).aspx

Note it says NTFS does not immediately write the LAT to disk. It will generally wait for the difference to be an hour or just piggyback itself to changes written to that file. File based queries, however, will be correct.

This isn't an auditing tool. There will be instances where NTFS will not update the LAT at the cost of performance. If you are looking for an auditing tool, I would suggest you turn on local security auditing. It will log all access to a file, unlike LAT. For example, there are numerous API calls you can use that will not affect the LAT.

Edit Response to comment below.

Will be reading this - but a) I was actually most concerned with the LMT and b) not even the size and contents of the file did change - Can it be program dependent ?? It most definitely shouldn't. I am starting to appreciate Unix and the i nodes here - EDIT : the size and times are not supposed to propagate (need confirmation on this) but the contents should

The article specifically addresses your exact issues. I'll quote the article. Emphasize was added by me.

The file content should have changed otherwise you didn't do it right.

Because a hard link is a directory entry for a file, an application can modify a file by using any of its hard links. Applications that use any other hard link can detect the changes. However, directory entries for hard links are updated only when a user accesses a file by using the hard link. For example, if a user opens and modifies a file by using its hard link, and the size of the original file changes, the hard link that is used to access the file also shows the new size.

So while the file itself was changed, the corresponding directory entries will not be updated, unless they are being accessed. So if you have a text file opened through two corresponding hardlinks, then both directory entries will change. Now if you only have the file open through hardlink A, hardlink B will not be updated. The file will have whatever changes you made. But again, hardlinks are directory entries, and NTFS does not update the directory entry if you aren't using it. It would be a waste of I/O.

Now I assume you are looking at all this through Explorer. Explorer lists information much like typing dir at the cmd line. A directory listing is just that, a listing. Reading a directory list does not access the file however, which is important. Otherwise, getting a directory listing will cause all the file's last access time to change!! So thus you will get outdated information if a hardlink is there. You can force Explorer to access the file by right clicking and say, check the details tab. Or just opening the file.

edit3

not entirely getting the difference - when hitting ^c then ^v on a foo.txt (so windows creates a file like foo - Copy.txt and places it in the current directory) - is this copying in which sense ?

This was tricky cause I have no idea how Explorer handles copying an existing file into its current directory. So I had to test this one. Looks like Explorer copies the source file target, whether the source file is a hardlink or a symlink.

Explorer doesn't have very granular control and support for symlinks and hardlinks. Now, it is possible to copy the link itself, if you do "mklink /h Foo1.txt Foo.txt". This creates a new hardlink called Foo1.txt. You can't do it in Explorer though. I suggest you get the Link Shell Extension. It overlays links with custom shortcut arrow icons, enumerates targets, and allows explicit creation of symlinks and hardlinks.

Edit4

well according to surfasb I do understand this correctly - a limitation of the filesystem - I now appreciate the inode concept. Anyway - strange thing - this is not always the case - sometimes the change in the attributes is immediately visible back to the original file - when there is change - my real concern now is that at least one program I am using does not seem to edit the file linked but only the hard link. Possible ? dir /a does not reveal much about hard links - any way to see them

I don't remember seeing this part of your question. I'm curious about the program that does not edit the file linked. Which program is this?

A dir /a will not update directory entries. This is by design, because it would be rather performance intensive.

Improve this answer
9
  • 1
    Will be reading this - but a) I was actually most concerned with the LMT and b) not even the size and contents of the file did change - Can it be program dependent ?? It most definitely shouldn't. I am starting to appreciate Unix and the i nodes here - EDIT : the size and times a re not supposed to propagate (need confirmation on this) but the contents should
    – Mr_and_Mrs_D
    Jul 6, 2011 at 18:14
  • I'll update my answer.
    – surfasb
    Jul 6, 2011 at 18:37
  • Thanks - as you see I quoted the same part of the answer myself - now as far as I can see the file itself has not changed. As for the quote - sometimes (depending on the program) the change in LMT is immediately reflected to the file (details view in explorer). Inconsistency. I put a +1 but not a tick yet - my real question now that file attributes are out of the way (almost) is if there are documented instances of programs failing to modify the file via its hard link. I repeat the same program does not resolve symbolic links at all - suspicious.
    – Mr_and_Mrs_D
    Jul 7, 2011 at 8:20
  • 1
    The most common way hardlinks are broken is by creating a copy of the file. Note, this is different than copying a file. Creating a copy of the file tends to avoid the "file in use" errors. A lot of text editors will do it this way. Office, instead makes a copy of the file first, then edits the copy. Then it deletes the original. Then it renames the copy. This is different than a program that creates a copy, deletes the original, then renames the copy. The later method breaks the link. Older backup programs use the later method, which can create havoc on Windows.
    – surfasb
    Jul 8, 2011 at 0:09
  • not entirely getting the difference - when hitting ^c then ^v on a foo.txt (so windows creates a file like foo - Copy.txt and places it in the current directory) - is this copying in which sense ?
    – Mr_and_Mrs_D
    Jul 12, 2011 at 11:51

You must log in to answer this question.

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