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.
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
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.
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.
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?
dir /a will not update directory entries. This is by design, because it would be rather performance intensive.