A blog on the Microsoft website from the Storage Team:



The unix time stamp is a way to track time as a running total of seconds. This count starts at the Unix Epoch on January 1st, 1970. is a system for describing points in time, defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1, 1970, not counting leap second

**************

(reference_date)

an excellent chart showing different time epochs

(1601 was the first year of the 400-year Gregorian calendar cycle at the time Windows NT was made.)

**************************************************************

Excerpts from: A blog on the Microsoft website from the Storage Team:



An observant Windows Vista user noticed a registry named NtfsDisableLastAccessUpdate under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem and asked us what this means.

Last Access Time is a file attribute that’s updated when a file is accessed or otherwise touched. (This is often confused with the Last Modified Time, which is only updated when the file changes.) Last Access Time has a loose granularity that only guarantees that the time is accurate to within one hour.

In Windows Vista, we've disabled updates to Last Access Time to improve NTFS performance. If you are using an application that relies on this value, you can enable it using the following command:

Create the following registry key on your run-time image:

Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

Name: NtfsDisableLastAccessUpdate

Type: REG_DWORD

Value: 1

*********************************************************

'Entry Modified'. The latter refers to the time when the MFT entry itself was modified

************************

(VS.85).aspx

A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC). The system records file times when applications create, access, and write to files.

The NTFS file system stores time values in UTC format, so they are not affected by changes in time zone or daylight saving time. The FAT file system stores time values based on the local time of the computer. For example, a file that is saved at 3:00pm PST in Washington is seen as 6:00pm EST in New York on an NTFS volume, but it is seen as 3:00pm EST in New York on a FAT volume.

Timestamps are updated at various times and for various reasons. The only guarantee about a file timestamp is that the file time is correctly reflected when the handle that makes the change is closed.

Not all file systems can record creation and last access times, and not all file systems record them in the same manner. For example, the resolution of create time on FAT is 10 milliseconds, while write time has a resolution of 2 seconds and access time has a resolution of 1 day, so it is really the access date. The NTFS file system delays updates to the last access time for a file by up to 1 hour after the last access.

To retrieve the file times for a specified file, use the GetFileTime function. GetFileTime copies the creation, last access, and last write times to individual FILETIME structures. You can also retrieve file times using the FindFirstFile and FindNextFile functions. These functions copy the file times to FILETIME structures in a WIN32_FIND_DATA structure. When writing to a file, the last write time is not fully updated until all handles that are used for writing are closed.

To set the file times for a file, use the SetFileTime function. This function lets you modify creation, last access, and last write times without changing the content of the file. You can compare the times of different files by using the CompareFileTime function. The function compares two file times and returns a value that indicates which time is later or returns 0 (zero) if the times are equal.

If you plan to modify file times for specified files, you can convert a date and time of day to a file time by using the SystemTimeToFileTime function. You can also obtain the system time in a FILETIME structure by calling the GetSystemTimeAsFileTime function.

To make a file time easy to display to a user, use the FileTimeToSystemTime function. FileTimeToSystemTime converts the file time and copies the month, day, year, and time of day from the file time to a SYSTEMTIME structure.

File Times and Daylight Saving Time

You must take care when using file times if the user has set the system to automatically adjust for daylight saving time.

To convert a file time to local time, use the FileTimeToLocalFileTime function. However, FileTimeToLocalFileTime uses the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, it takes daylight saving time into account, even if the file time you are converting is in standard time.

The FAT file system records times on disk in local time. GetFileTime retrieves cached UTC times from the FAT file system. When it becomes daylight saving time, the time retrieved by GetFileTime is off an hour, because the cache is not updated. When you restart the computer, the cached time that GetFileTime retrieves is correct. FindFirstFile retrieves the local time from the FAT file system and converts it to UTC by using the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, FindFirstFile takes daylight saving time into account, even if the file time you are converting is in standard time.

The NTFS file system records times on disk in UTC. To account for daylight saving time when converting a file time to a local time, use the following sequence of functions instead of using FileTimeToLocalFileTime:

• FileTimeToSystemTime

• SystemTimeToTzSpecificLocalTime

• SystemTimeToFileTime

File Times and CDFS

The date and time stamps of files that are located on or originate from media using Compact Disc File System (CDFS) are adjusted for the local time zone. ISO 9660 states that CDFS is to display the date information correctly for the local time zone. This is done so that dates for files on CDFS are displayed the same as those on Universal Disk Format (UDF). UDF is the newer standard for distribution media. If your code depends on the unmodified date information for a file that resides on or originates from media using CDFS, it may not function correctly.

Send comments about this topic to Microsoft

****************

What time is it? The problem

"What time is it?" Most people would have no problem answering this question. But a computer forensics examiner might.

PST, EDT, CST, GMT, ZULU. Do these abbreviations mean anything to you? If you deal with operating systems other than DOS they should. They are time zone designations. Some programs rely on and make use of these terms.

For an investigator dealing with computer evidence, how important is the time (clock) setting on the suspect computer? It can make or break any case that relies on placing the suspect at his computer at a specific time.

A hypothetical case

Suppose a hacker has penetrated your system and is downloading files to his computer. Suppose you are in Greenwich, England and have monitored his activity on your computer. The time on your computer says 12:00 hours GMT. The next day the suspect’s computer is seized and sent for analysis. (The suspect lives in Washington D.C.). It is determined that the suspect is using Windows NT and has the NTFS file system set up.

The only way to convict the suspect is to show that your files showed up on his computer within 5 minutes of the time you were monitoring the activity. Your exact request to the examiner stated that you "needed to identify files downloaded at 12:00 hours."

The examiner performs accepted system handling techniques, including backup/imaging of a Windows NT system and looks for files with a time of 12:00 hours. None are found. What has happened? What should the examiner be looking for?

Perhaps the crucial piece of evidence is the time setting of the seized computer. That setting will determine the time stamps that are applied to new or modified files. For this reason, it’s important to record the local time setting on that computer. Also, it is likely that the seized computer's setting does not correspond exactly with the correct local time. So, you should record how far off the correct local time the computer setting is. (Most users are content to have the computer’s internal clock set to within a few minutes of local time.)

Another setting that may be important is the TZ (time zone) variable. This variable is usually set in DOS via the autoexec.bat file, or under NT in the Control Panel. It will indicate which time zone the suspect computer is using.

Even if the computer clock is determined to be accurately set, any file the suspect may have created during your time period would not reflect 12:00 hours GMT. It would more likely reflect local time of 07:00 or 08:00 hours depending on whether Daylight Savings Time was set and in effect during this period. (Don’t forget, Washington D.C. is 4 or 5 hours off GMT). But the examiner still can’t find any files with a time setting matching your 12:00 hours. Why not?

When you use File Manager or the DIR command to display file times, NT shows you the time the file was last written to. From that point on, NT and 9X may handle file times somewhat differently. (WIN95 is similar to NT in its treatment of timestamps. But not 100% compatible. Certain differences will be noted below.)

Assume the suspect didn’t do any writing to the files. All he did was copy them to his system, and maybe he used a program to view them. There are a variety of "copy" operations (ex.: FTP; a simple file "copy"; telnet) and they affect timestamps differently. Depending on the operations of the suspect's copy process, the operating system might now display the original file times recorded on your host system, which is not the 12:00 you are looking for. Let's assume you still don’t have a time match because the timestamp on the files on your system( which have now been transferred to the suspect computer) are nowhere near the time in question. The time stamp on your host files reflect when you last changed the file. Where to next?

Well, once your examiner straightens out the differences for the suspect’s local time setting, the next step is to check the last access time of the files. What’s that?

Three types of timestamps

With operating systems such as UNIX, LINUX, WIN9X, Windows NT and others, file times (and dates) are stored as three separate items. These are: (1) the creation time;(2) last write/modification time; and (3) last access time. Let's look at these.

"Creation time" is usually (but not always) the time the file was created. More specifically, it is the time when the file was first created or written to the disk. Note, then, that if the file was copied from another source, "creation time" would be the time the file was copied rather than the time it was first created. (Microsoft documentation roughly defines this as: the time the file was created. A value of 0,0 indicates that the file system containing the file does not support this time member.)

"Last write/modification time" may take on many different meanings. Practically speaking, it means when a program last made any changes to the file. Even though Microsoft defines it as last write time, if you consider this to be the last modification time, all the behavior of the operating system relative to this time stamp seems to be correct. Last modification would occur when you re-opened the document, edited it in some way, and wrote the result back to the disk. This is the time File Manager and DIR show you. (Microsoft defines this as: the time that the file was last written to. All file systems support this time member.)

Believe it or not, when an original file is copied (using the copy command or File Manager) both NT and 95 keep the original "last write/modification" time on the new file. However, the creation time is, by definition, the current time of the copy.

This is a source of confusion. How a file can be created after it is modified? The answer lies in the way the operating system maintains its timestamps. If the file in question was modified(written to) on the examiner's computer in Greenwich last week, that is the time File Manager will display on the suspect disk. Oddly enough, the "creation time" of the file on the suspect disk actually reflects the time the file was copied by the examiner. But the operating system doesn’t display that.

The trick to solving the time problem may involve the third type of file time, "last access time." This generally means the last time some action was taken on the file. It can include the last time the file was: copied; viewed with a viewer (such as Quick View Plus); opened for reading; or printed with a piece of software. (Microsoft defines this as: the time the file was last accessed. A value of 0,0 indicates that the file system containing the file does not support this time member. )

Generally, the NT system resets this "last access time" any time an action is performed on the file. And most activity on a file (except for doing a simple DIR) will cause this time to be reset. The examiner must test the operation of each software program used by both the suspect and by himself to determine if any of that software alters last access time.

So, how is last access time actually determined? Windows NT and 9X normally do not provide the capability of viewing any time except the last write time. As mentioned earlier, the last write time is the default for File Manager or DIR. The examiner would need custom software to view the last access time. Software exists that will do this, but that’s not for this article.

(Note: WIN9X does not appear to completely support the last access time, even though much of the programming documentation written says this time is available. As best as I have been able to determine, WIN9X stores the last access date, but not the time.)

Floppy disks bring their own set of problems in determining last access time. Because of long filename capability, if the floppy is being used in an NT or 9X computer, all three date stamps seem to be in place and follow the WIN95 formats. This means the last access date is maintained (i.e., no time); and that the creation time and write date/ time are also maintained. However, that same floppy disk, when used in a DOS based computer, will only update the last write time since DOS can only handle one file time.

So, the examiner needs to find the correct last access time of the files and to adjust for time zone and internal computer clock differences. For NTFS and WIN95, he must carefully test all the software to see what effect it has on the various file times. And make certain he has software which can accurately depict these times.

Is that it? Recall that early in this article I mentioned that the examiner must perform all proper image/backup procedures. Suppose that one of these procedures involved either performing some sort of CRC file verification or using a file viewing technique to see what files were on the suspect system. It is possible that the activity of the examiner, in performing these operations, has altered the last access time of the suspect files. If so, the examiner now has real problems.

What time is it? The Solution

Just as there are problems surrounding file times on Windows NT and WIN95 file systems, there are also solutions. In the discussion that follows, I will offer a short list of software, currently available on the Internet, that can keep your system clock synchronized to various "time servers" around the world. I will also present an overview of software I have written to make an investigator’s job a little easier when looking for and recording file times.

(Please note: for simplicity, when discussing file dates or times below, I use the term' date' to mean the combined file date and time.)

Help with setting your computer's time

First, let me list some programs I have found on the Internet which I use to set the correct time on my computer. Simply search the web for keywords in the filenames to locate the programs. These packages are designed to work under NT or WIN9X. Most of the authors also have versions for other operating systems. Most of these programs will not work through a firewall, and one is designed to work through a modem under MS-DOS. Some are free, some provide demo versions, and some are for sale.

You can also look at (, or ) for additional software. Most of the servers are located in the U.S. However, there are many other servers located all over the world. Here is a short software list: 4DTIME40.ZIP, ATOMCLK.EXE, NBSCOM.EXE, NETDATE.EXE, SNTP.EXE, YATS32.EXE.

Good forensic analysis practices--initial steps

Next, after correctly setting the time on your computer, good practice requires that you always work on an imaged copy of the hard drive, and that you have a write blocker installed. At a minimum, you will be using a file viewer to view suspect files. File viewing and most file operations will attempt to alter the access date of a file. If a write blocker is installed, it may not allow this. And that presents a problem. You can turn off the write blocker when viewing files and performing other operations, or live with the inconvenience that it presents. (At this point, I will assume your write blocker is inactive so you can use your viewer and that you are working on an imaged copy of the evidence.)

If you do not have a write blocker, (and even if you do), you might want to consider using the "accdate" command in the config.sys file to turn off access date updates.

For the remainder of this article, I will present a procedure and some file cataloging or inventory programs that will provide you with a strong defensible position when facing challenges about file dates. I will generally assume the investigator is using Windows NT. However, most of the techniques (except those dealing with last access time) will also work on WIN9X file systems. Remember that in considering the procedures discussed below, you also must always bear in mind what constitutes acceptable evidentiary procedures within your own jurisdiction. Each country and each agency within that country may have specific regulations concerning processing of evidence and the procedures discussed below may need to be altered to be consistent with those requirements.

Documenting file dates with an inventory

At the earliest possible point during the analysis the investigator should create an inventory of all files on the system. (The simplest command is: DIR /AHS.) Most software lists the last modified date of a file because that is what File Manager and DOS present. Sometimes this file date may not be the best choice; or, you might want to record one or both of the other file dates as well (see the three types of timestamps discussed earlier.)

I created and use in my own forensics work a very useful inventory program, Maresware's Hash. This program will produce a list (also referred to as a "catalog" or "inventory") of every file on the disk. The output record produced includes: file names; file sizes; MD5 hash value of the files; and one of the three types of file dates (whichever one you selected).

A good practice in using Hash for your inventory procedure is to run it first to produce a list of every file with its last access date. (Remember 9X doesn’t use last access time, just the date. On WIN95 systems the last access time is 00:00). Then run the program again to list the last modification date; and run it a third time to record the creation date. Running the program as the initial step in your examination will provide a "checkpoint" of the status of the files before any forensic analysis was done. Later on, if the examiner has used a tool which may have altered the last access date, he has an arguable defense: proof of what the original access date was. This may be a very important file date. (See the note at end of this article.)

But why include the MD5 hash values in the inventory? Because they have enormous value in ensuring file integrity. It provides you the critically important ability to demonstrate that your examination did not alter any part of the original file/evidence. CRC, Checksum, or Hash/Signatures of a file are all values derived by a mathematical calculation which uses every bit of the file. Depending on the algorithm used, the chances are from roughly 1 in 64000, to 1 in 2 times 10 ** 34 (that’s 10 with 34 zeros) that two dissimilar files will produce the same value. When two dissimilar files produce the same value that is referred to as a "collision".

If a strong algorithm is used to calculate the initial value of a file, then at a later time if that value has not changed, there is a near-certainty that the contents of the file have not changed either. MD5 is the algorithm where the chances of 2 dissimilar files having the same value is 2 times 10 ** 34. By searching the Internet for the keyword ' MD5' you can locate voluminous documentation describing the operation and reliability of this particularly strong algorithm.

This simple procedure of creating an inventory of all files on the system, with its three types of file dates, is the single most important step in a computer forensic examination. I created Hash with sufficient capacity to handle the large number of files found on today's systems. I frequently find over 10,000 files on a stand alone computer. And networks compound the number of files which need to be catalogued.

There are several other Maresware programs, discussed below, which are useful in producing file inventories. They operate in slightly different ways, and an examiner might need to use one, or all, for different tasks.

The second Maresware program, Diskcat, can also record all three dates. Diskcat, short for "disk catalog," produces a catalog of every file on a disk or diskette. It lists the filename, date, and size. It can also generate a 32 bit CRC, and show what type of program generated the file. It does all this in a fixed length record format, which makes the output easy to import into a database for further analysis(a feature I find enormously helpful). This program only changes the last access file time when the CRC is requested. All other modes of operation do not alter any file times. (See note at end of this article)

Another Maresware inventory program is Crckit. This program will calculate the 32 bit CRC of a file. It can also list any of the three file dates chosen. Crckit also attempts to reset the file dates so no significant alteration is produced. It does not have all the capabilities of Hash and is mainly used for single directory listings. However, for a file by file validation, it is excellent. (See note at end of this article)

A final Maresware inventory program is Mdir. It is designed as an" intelligent" replacement for the DIR command. Mdir produces an output listing with the look and feel of the DIR command, but provides much more capability. One of its features is the ability to provide any one of the three file dates based on the user's choice. It is a "quick and dirty" method of doing an intelligent DIR of a directory.

In summary:

Prior to beginning a forensic examination, the investigator should make sure that the forensic(examiner's) computer has the correct time set. This can be accomplished using appropriate software to synchronize the computer’s clock with a recognized time standard. Also, the examiner should record the time on the suspect's machine to determine the difference in computer times.

As a first step, before any computer forensics examination begins, the investigator should create a listing/catalog of every file on the suspect system with its corresponding date and time(and, preferably, including calculations of the related hash values).

Especially when dealing with advanced operating systems like Windows NT and WIN9X, the examiner needs to perform his work constantly mindful of the fact that the system maintains three file dates and that almost any operation he performs will alter the last access date.

Notes:

Maresware's Hash, Diskcat, and Crckit, when requested to calculate the MD5 or 32 bit CRC of a file, all open and read the file in order to compute the values. Because they open the file for reading, the operating system resets the last access date of the file. There is no way around this.

However, the programs are designed with the ability (at the user's request) to restore the date on all files to the original value. This restoration of original date does make changes to the disk, but produces no significant alterations. With advanced operating systems in use today, it becomes almost impossible to run a system without the operating system itself changing items on the disk. You must be prepared to explain that and to state your reasons for turning on the system.

If this changing of the date back to its original value poses a potential evidentiary problem, then the user should use the Hash or Diskcat program and NOT request the MD5 or CRC calculation. This operation without any calculations will not open any file and will produce only a catalog of the disk. In this mode, no file opening takes place, and the operating system doesn’t alter file dates. But all you get is a file listing, and no numeric validation as to the integrity of the file. You must make a choice as to which you prefer. If you are conducting the examination using an imaged copy of the evidence, as you should be, this is not the problem it might appear to be. After capturing the three dates, you simply run the programs again, and let the operating system alter the dates in its usual fashion. You have the original dates recorded, and you are prepared to explain the operating system's process of changing the dates.

One last note: remember that under NTFS, the last access time is updated only on an hourly basis.

*******************



3 File properties with regards to the date and time stamps

• [pic]If you copy a file from C:\fat16 to C:\fat16\sub, it keeps the same modified date and time but it changes the created date and time to the current date and time.

• If you move a file from C:\fat16 to C:\fat16sub, it keeps the same modified date and time and keeps the same created date and time.

• If you copy a file from C:\fat16 to D:\NTFS, it keeps the same modified date and time but changes the created date and time to the current date and time.

• If you move a file from C:\fat16 to D:\NTFS, it keeps the same modified date and time and keeps the same created date and time.

• If you copy a file from D:\NTFS to D:\NTFS\SUB, it keeps the same modified date and time but changes the created date and time to the current date and time.

• If you move a file from D:\NTFS to D:\NTFS\SUB, it keeps the same modified date and time and keeps the same created date and time.

• In all examples, the modified date and time of a file does not change unless a property of the file has changed. The created date and time of the file changes depending on whether the file was copied or moved.

*******************



File time stamps on FAT drives are rounded to the nearest two seconds (even number) when the file is written to the drive. The file time stamps on NTFS drives are rounded to the nearest 100 nanoseconds when the file is written to the drive. Consequently, file time stamps on FAT drives always end with an even number of seconds, while file time stamps on NTFS drives can end with either even or odd number of seconds.

When files are copied from NTFS drives to FAT drives, some file time stamp rounding has to occur; the file time stamp is rounded up to the next even second.

To preserve exact NTFS file times, always copy files from NTFS drives to other NTFS drives. If you are writing a program to compare file times between NTFS and FAT drives, accommodate for the expected rounding.

****************



The NTFS date is stored as the number of 100 nano seconds since 1st January 1601. As this is a 64 bit number, rather than a 32 bit number this will run until 60056, by which points its fair to say Micrsoft will have moved on from NTFS. Unix date/time offset which starts from 1970 and runs out in 2038.

MFT Entry Modified: A basic understanding of NTFS and the MFT is required for this section. This is date not shown by Windows Explorer or the average windows interace, but requires forensic tools , e.g EnCase, FTK, iLook, WinHex, etc.  This date shows when the MFT entry, which points to the file of concern, was changed. This means that if the record that points to the file  is changed, then this date would trip. As all the dates, file name, file sizes are stored in the MFT, if any of those are changed then the date will change. For example, if the file szie change then the MFT Entry modified date is changed. If the fike name is changed, than the MFT entry modified is changed.

********************

LINUX:

ctime, atime, and mtime

It is important to distinguish between a file or directory's change time (ctime), access time (atime), and modify time (mtime).

ctime -- In UNIX, it is not possible to tell the actual creation time of a file. The ctime--change time--is the time when changes were made to the file or directory's inode (owner, permissions, etc.). The ctime is also updated when the contents of a file change. It is needed by the dump command to determine if the file needs to be backed up. You can view the ctime with the ls -lc command.

ctime -- In UNIX, it is not possible to tell the actual creation time of a file. The ctime--change time--is the time when changes were made to the file or directory's inode (owner, permissions, etc.). It is needed by the dump command to determine if the file needs to be backed up. You can view the ctime with the ls -lc command.

atime -- The atime--access time--is the time when the data of a file was last accessed. Displaying the contents of a file or executing a shell script will update a file's atime, for example. You can view the atime with the ls -lu command.

mtime -- The mtime--modify time--is the time when the actual contents of a file was last modified. This is the time displayed in a long directoring listing (ls -l).

Dan Farmer: it is crucial to note the word last. MACtimes only keep track of the last time a file was disturbed

Atime:

read a file

Modify the permissions

modify the ownership

create new file

Ctime:

modify the permissions

modify the ownership

modify the first level of contents of a directory

create new file

Mtime:

modify the contents of a file

create new file

******************

10/2008

SUMMARY

This article describes how file and folder date and time stamps (created or modified) are displayed based on the file system that is in use (FAT or the NTFS file system), and the partition (whether the action occurred on the same partition or across partitions).

Back to the top

MORE INFORMATION

File properties with regards to the date and time stamps

• If you copy a file from C:\fat16 to C:\fat16\sub, it keeps the same modified date and time but it changes the created date and time to the current date and time.

• If you move a file from C:\fat16 to C:\fat16sub, it keeps the same modified date and time and keeps the same created date and time.

• If you copy a file from C:\fat16 to D:\NTFS, it keeps the same modified date and time but changes the created date and time to the current date and time.

• If you move a file from C:\fat16 to D:\NTFS, it keeps the same modified date and time and keeps the same created date and time.

• If you copy a file from D:\NTFS to D:\NTFS\SUB, it keeps the same modified date and time but changes the created date and time to the current date and time.

• If you move a file from D:\NTFS to D:\NTFS\SUB, it keeps the same modified date and time and keeps the same created date and time.

• In all examples, the modified date and time of a file does not change unless a property of the file has changed. The created date and time of the file changes depending on whether the file was copied or moved.

Back to the top

Folder properties with regards to the date and time stamps

• If you create two new folders on an NTFS partition called D:\NTFS1 and D:\NTFS2, both the created and modified date and time are the same.

• If you move the D:\NTFS2 folder into the D:\NTFS1 folder, creating D:\NTFS1\NTFS2, then:

1. D:\NTFS1 - The created folder is the same and the modified stamp changes.

2. D:\NTFS1\NTFS2 - Both the created folder changes and the modified folder stay the same.

This behavior occurs because, even though you moved the folder, a new folder is seen as being created within the D:\NTFS1 folder by the Master File Table (MFT).

• If you copy the D:\NTFS2 folder into the D:\NTFS1 folder, creating the D:\NTFS1\NTFS2 folder, and the D:\NTFS2 folder still exists (after having copied it):

1. D:\NTFS1 - The created folder is the same and the modified folder time and date stamp changes.

2. D:\NTFS2 - No changes occur because it is the original folder.

3. D:\NTFS1\NTFS2 - Both the created folder and the modified folder changes to the same stamp, which is that of the time of the move.

This behavior occurs because even though you copied the folder, the new folder is seen as being created by the MFT and is given a new created and modified time stamp.

Note: The design and behavior of the FAT file system is different with regards to the modified time stamp. On a FAT file system, the modified date of a folder does not change if the contents of the folder change. For example, if you have D:\FAT1 and D:\FAT2, and you copy or move D:\FAT2 into D:\FAT1, the created date and modified date of D:\FAT1 remains the same.

-------------------

General Explanations:

Date and Time types

The File Created column is a record of when a particular file was created at that location or on that media. If a file is edited and changed on January 3rd, then copied to a floppy diskette on January 15th, and then that floppy diskette is acquired on January 28th, it would show that the file (on the floppy) was created (on January 15th) which is after it was last written (assumed to be January 3rd) or even accessed (on January 28th).

The Last Written column displays the last date and time that a file was actually opened, edited or modified, and then saved. The last written date could be changed if the file is opened and printed and the users positively responds to the dialog box requesting for the file to be saved. Since Microsoft considers a printing of the file to be a change, as it changes the internal meta-data of the file. If a file is opened then closed, but not altered, the last written date and time do not change.

The Entry Modified column, pertinent to NTFS (Windows NT, Windows 2000, Windows XP, and Windows 2003 Server) and Linux file-system files, refers to the pointer for the file-entry and the information that that pointer contains, such as the size of the file. If a file was changed but its size not altered, then the Entry Modified column would NOT change. However, if the file size has changed (from eight sectors to ten sectors, for example), then this column would change.

The Last Accessed column displays a date of the last access date of the file. A file does not have to be altered for the last accessed date to change—only accessed. Any activity (such as viewing, dragging, or even right-clicking) may change the last accessed date. The last accessed date may also change if the file is accessed by a program such as a virus checker. The last access date update functionality can be turned off via a registry entry, and the more recent versions of Vista have it turned off by default.

What is the difference between Entry Modified and Last Written dates? Entry Modified refers to the date and time an NTFS MFT entry was modified, and does NOT necessarily have any bearing on the file contents. The Last Written date and time refers to the file itself being written to.

--------------

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download