Why creation time remains the same?

You should be able to find plenty of white papers around to describe this in detail, but essentially it boils down to this.

When you "copy and paste" you are creating a new file, so it must have a new created time stamp, depending on the OS often the 'created' time of the original document will become the 'edited' time of the new copy.

When you "cut and paste" you are not creating a new document, you are simply moving the location of the original file, hence no change to time stamps.

There are other factors that will have an effect on this such as NTFS or FAT32, Windows vs Linux or Mac etc, so this is far from a simple issue that it may appear.

Thank you Adam10541. I am confused because when a file being "cut & paste" to the destination volume, this file is new to this volume,right? So it should be the same as "copy & paste" to the destination volume…

What I am trying to say is that if the creation time means "the change to the destination volume", then "copy & paste" and "cut & paste" should be the same thing. Because that file is not in the destination volume before "copy & paste" or "cut & paste".

gorvq7222,

My understanding is that Windows computers will create and store only one (1) copy of every User generated files in protected storage.

Then, if other others are given access to the original protected file and make changes, Windows will NOT alter the original User's version of the file, but rather will only store a file of the CHANGES to the original file that the additional user made.

I believe the concept is the same as how email databases will hold only one unique copy of an email, but create and maintain additional "pointers" to the original email if the user, for example, copies the email to a new email folder; the email database is NOT creating a second copy of the original email and placing the new copy in the new folder.

So, in your scenario, if a file on a Windows system is "copied" to another folder on the same Windows system, the Windows operating system is NOT creating a new copy of the file, but simply creating a new "pointer" to the original file.

Regards,

Larry

Yes it's new to the volume, however it's the operating system that dictates the time stamp behavior and it's aware that this is a file that is simply being moved, hence no new time stamps required.

If you were to cut and paste that file across a network to a machine running a different version of Windows or Linux then the result may be different as the OS of the new host machine may have different rules. I'm not sure exactly what would happen in this instance but the golden rule is to run tests yourself and don't take it for gospel that what we are telling you is correct.

Personally, i think there is room for improvement in Windows NTFS timestamps.

(Click image to expand the size)

Personally, i think there is room for improvement in Windows NTFS timestamps.

How so?

What I am trying to say is that if the creation time means "the change to the destination volume", then "copy & paste" and "cut & paste" should be the same thing. Because that file is not in the destination volume before "copy & paste" or "cut & paste".

There are multiple layers of software involved here.

At the bottom you have NTFS, the file system. To NTFS, there is no such thing as copy and paste, there is only system calls – and I'm fairly certain that copying a file using the CopyFile system call over volume boundaries does what you think it should. To NTFS, the destination file is a new file.

However, then you have Windows Shell, which adds the GUI and 'user friendly' modification. When you copy a file, it's Windows Shell that adds the 'let's keep the original time stamps, as that's what the user wants', once the basic copy has been done by NTFS.

Why Windows Shell it chooses to do things the way it does – is really of very little interest to computer forensics. For that, I suggest you ask Microsoft or any of the MSDN bloggers who seem to be able to find these things out. Microsoft have done so strange things with the user interface recently that additional strangeness does not surprise me very much.

What is important for forensics is knowing what happens under different
circumstances, and preferrably being able of replicating it consistently.

Personally, i think there is room for improvement in Windows NTFS timestamps.

How so?

Because

1. The only timestamp you can disable in Windows NTFS is the Last Access Timestamp using a registry setting.

2. The (WAV) file in the picture was downloaded about in sept 2014, i know why i downloaded it and therefore also when i downloaded it.

With these things in mind, the image in my post should make things clear.

EDIT This image link appears to works better, except that it kills the rightmost field (Last access time) and you have to use "View Image" to see the full image.

I am not sure that there is anything odd about the graphic or what it is saying (other than the column labelled "date" - what date is this?)

On 24/9/2014 you downloaded a file the content of which had has not beeen modified since 2009. As you created a new copy the created date was updated to the date of the copy operation 24/09/2014 and the access date also updated.

on 04/12/2015 you made (created) a new copy so the created date of the new copy was set appropriately but as you never editted either copy the modified date stays the same.

I have got a bit of a hangover (first christmas party) so I can't see what I am missing or what improvements MS could make to the timestamps to make this clearer.

The only possibility I see of anything that is less than clear is the last accessed date of test_org. As you have accessed this file to make a copy this date would normally (as in you would expect) be updated to reflect the access for the copy operation. But as you mention last access can be disabled and lazy writes for last access can be in play. This is expalined in a number of places online - this being one

https://technet.microsoft.com/en-us/library/cc781134%28v=ws.10%29.aspx