Furthermore, the last written time in the registry is 84225am and the files along with lnk files in my documents start at 84233am and continue to 84912am.
It was my understanding that the Last Written registry timestamps, that you're referring to, indicate when the USB device was connected to the computer (although I stand to be corrected by those more knowledgeable on registry matters ) ). So the times you refer to could in fact indicate that the USB device had been connected at 084225, and then files were copied to the device between 084233 and 084912 - is there any registry key that indicates when a USB device has been unplugged ?
If that is the case, then it is fairly strong evidence that the current user was opening these files. Personally I can't think of any program which runs in the background and changes not only the last accessed time but creates a lnk in the Recent directory.
This is only speculation, but might it be possible for some backup software to exhibit this kind of behaviour ? The file is backed up to the external USB device (changing the Last Accessed timestamp for the file), then the original file is accessed in order to verify that the backup operation completed successfully (possibly creating the .lnk file ?).
For example. I just checked a document in my documents named test.
The lnk file
Created 6/17/2010 54709am
Accessed 6/21/2010 84313am
Modified 6/17/2010 54810am
Actual file
Created 6/17/2010 54708am
Accessed 6/21/2010 84316am
Modified 6/17/2010 54708
Additionally, this document is listed in recent docs with same timestamps
Also, this is 1 file it's going on with hundreds.
About to the bottom of the barrel with this. I hate to speculate but finding the external drive "if" it were for sure used would be very different.
To further complicate matters, if you highlight a series of files, and Copy them to the thumbdrive, only some of those files will have their Last Accessed updated.
Not sure why, when I tested this (from NTFS to a FAT32 thumb drive), the files that had the timestamp updated all had Object ID attributes in their MFT record (with GUID values). Unfortunately, some of the files that had their Last Accessed updated did not have an ObjectID attribute in their MFT record - and were not fragmented either (I was trying to find the common denominator).
The definition that I've held to is that the Last Accessed timestamp is updated when, 1) the option to update Last Accessed is enabled in the OS, and 2) the metadata or contents of the file are read.
According to Carrier, "when a file is copied or moved, the access time on the original is updated to reflect that it was read". But what I'm seeing during a basic test is that the time is updated for only _some_ of the files.
Looks like this definition needs to be updated to account for exceptions.
According to Carrier, "when a file is copied or moved, the access time on the original is updated to reflect that it was read". But what I'm seeing during a basic test is that the time is updated for only _some_ of the files.
Looks like this definition needs to be updated to account for exceptions.
There's also the Chow et al. The Rules of Time on NTFS File System (2007), which suggests that batch copy may have a delay in access time updates, if the files involved are large. But it also indicates that a click on a file 'generally' updates its last access time, which I'm not sure is correct anymore … their test setup was XP SP2, and the tests seem to have been performed in 2006 .
consultit, have you read up on ShellBags in the link I posted earlier?
But it also indicates that a click on a file 'generally' updates its last access time, which I'm not sure is correct anymore … their test setup was XP SP2, and the tests seem to have been performed in 2006 .
It's still correct – though the test absolutely needs to involve a shutdown or a orderly dismount/eject of the drive to ensure the timestamps are written to disk. Relying on timestamps shown in the Explorer window, or returned from the C stat() system call does *not* always give you the latest Last Accessed timestamps. (Haven't tested GetFileAttributes() or FindFile() yet, though I expect either of those is what Windows Explorer uses for its values.)
Even just hovering the cursor over a file (i.e. without actually selecting it) until the popup appears, modifies last access timestamp.