[ Back to Table of Contents ]
[ << ]
[ >> ]
XXCOPY TECHNICAL BULLETIN #15
From: Kan Yabumoto email@example.com
To: XXCOPY user
Subject: Windows File Date and Time
File time in DOS
The good old DOS had just one file date value which keeps track of
a file in your storage (hard disk and floppy). To be precise, the
value has two parts, the date part (year, month, and day) and the
time part (hour, minute, second ---- measured in two second interval),
but we will call it just "file date" in this discussion.
Whenever a file is created, the current system time is stamped to the
file which would remain constant even if it is copied or moved to a
new directory. A complete rewrite, partial rewrite, or partial
deletion would update the file date value. Therefore, the DOS file
date represents the last-write (or, last-modified) time. It was
quite simple and well.
File time in Win32:
The new so-called Win32 environments (Windows 95, 98, NT, 2000)
expanded the file date to hold more information about the history of
the file. Win32 maintains three distinct time stamps on every file.
Inside Windows Explorer, you can examine these values in the property
sheet for a file.
1. Created: It is the time when the file is created in the
current directory. When the file is copied to a
new directory, a new value will be set.
2. Modified: It is the time when the file is last modified.
When the file is copied to elsewhere, the same
value will be carried over to the new directory.
3. Accessed: It is the time when the file is last accessed.
This value is set by the application program that
sets or revises the value. Unfortunately some
applications do not revise this value.
The file date value commonly referred to under Win32 is the "Last-
modified" value (2nd one in the list above) whose behavior is
consistent to the DOS file date value. The Win32 file date values
are stored in much finer resolution than the DOS time stamp (16 bits
for the date and 16 bits for time). The Win32 file date value
is a 64-bit quantity which represents the time elapsed from
January 1, 1601 (the first date of the current quadri-century)
in 100 nsec granularity. For the compatibility's sake, even WinNT/2K
uses the same 2-second granularity for the "Last-modified" time for
FAT-based file system (does not apply for NTFS files).
XXCOPY's file date treatments:
XXCOPY provides the following switches to select one of the
three timestamps as the filedate value for time comparison.
/FC File-Create time
/FW Last-Modify (Last-Write) time (default)
/FA Last-Access time
These switches do not perform any action by themselves. They
are used to modify the semantics of other switches which use
the file date parameters in the file selection process. For
example, /DA and /DB are often modified by the /FC switch.
The file date (Last-Modify date):
The common file date value (more precisely, the Last-Modify-date)
is the most intuitive and probably the easiest to use. So, by
default, XXCOPY's file date functions use the Last-Modify date by
default. For example,
XXCOPY c:\mydir\ d:\backup\ /DA#7
The /DA#7 switch selects files which are last modified within
the last 7 days. This selection includes files which are created
or modified elsewhere and brought to the source directory by
either a copy or move operation. The COPY or MOVE operations
carried out by practically all file copy utilities (i.e.,
Drag-and-drop, COPY, XCOPY, MOVE, or XXCOPY) preserve the file's
The file creation date (File-Create date):
Another useful date value is the File-Create date. Unlike the
Last-Modify date, this value represents the date the particular
copy of the file is created in the directory. Here, the meaning
of creation includes both the case of a newly created file, and an
existing file brought in to the directory by a copy operation.
So, the File-Create date is often newer than the Last-Modify date.
Note that sometimes, the "File-Create" date could be a little
misleading. But, in this article we use the "File-Create" date
consistent with the way Microsoft calls it.
With XXCOPY, you may use this creation-date value instead of the
more common Last-Modify date. Here is an example:
XXCOPY c:\mydir\ d:\backup\ /S /FC /DA:.
This command copies all the files which are either made in
or brought into their present directory today regardless of
the age of the file. With the /FC switch, XXCOPY uses the
File-Create date rather than the Last-Modify date. The
/DA:. switch selects files of today or a future date.
Since the use of the File-Create date has serious problems, we
generally discourage the use if this date
Problems with the file creation date (File-Create date),
The problems of the File-Create date can be traced back to
the inconsistency in Microsoft's various file management
utilities. It seems that the purpose of three distinct
variations in the file date values were never clearly defined
by the designer of the feature. We as software developers
have not come across any official documents on this subject.
So, we conduct a few experiments using Microsoft's programs
which are part of Windows 95. Then, you will find many
inconsistent usages in the File-Create date.
Observation 1: When you perform a copy operation of a file
which results in a new physical copy in the
destination, the File-Create date is set to
the current date.
Observation 2: When you move a file within a volume, the
operation is translated to the more efficient
renaming operation. Since renaming a file does
not involve in a newly created file, the File-
Create date will not be updated.
Observation 3: When you move a file across the volume boundary
(e.g., from C: to D:), the move operation is
carried out as a file copy action followed by
a file delete action, the file in the new
location will receive a new File-Create date.
Observation 4: Edit a file using either NotePad.exe, WordPad.exe
or WinWord.exe (word), and save the file. The
newly update file will have the same File-Create
date, but a new Last-Modify time.
The inconsistencies listed above make the File-Create date unfit
for a general-purpose file selection criterion by XXCOPY. On
the other hand, if you have full control of the file creation
process in a given directory (say, you always use one of the
file copy operations to manage files in the directory), you may
still use it with caution.
The case with the Last-Access date:
This parameter is also a very controversial value that goes with
every file in the Win32 system. The Last-Access date is set whenever
the file is "Accessed" by a program. Then, the next question is
what really constitutes an "Access" to a file?
Is opening the file by a program, by any program, treated as an
"Access"? Thank God, the answer is no. If that were the case,
whenever the Windows Explorer displays an executable file using its
icon (which is stored inside the file), the Last-Access date would
be set to the current date. That is because display of the icon
involves fist opening the file and reading the contents to locate
the internal icon. In this case, although the treatment of the icon
is rather elaborate under the cover, it is not regarded as an "Access".
On the other hand with .EXE and .DLL files, executing the program
constitute the Last-Access. That makes sense.
But, there are plenty of silly mistakes committed by Microsoft's
programmers which makes the Last-Access date of little use. The
possibly the worst program mistake with this value is by Windows
As shown above, when you click the right button on an icon of a file
and select the properties menu, you can examine the Last-Access date
(in this case you get only the date without time) along with the other
two file date values. But, if you are alert, you will notice that
the Last-Access date is always today's date. Yes, the very act of
examining the Last-Access date value triggers the update of the value.
That is sad. Very sad.
When a system administrator makes a regularly scheduled backup, he
usually performs a full backup every so often, copying every file
in a drive. Now, that is an act of Access. Copying a file will
also update the Last-Access date.
If Microsoft's programmers had been very careful not updating the
Last-Access values under certain common file access cases, this
value could have become a very useful parameter in file selection
for file management (backup) activities. Unfortunately, they wrote
so many programs that ignored the designer's apparent intention.
Now, it is too late. The Last-Access date is even more useless
than the doomed File-Create date.
We recommend the use of /FC (File-Create date) only in carefully
controlled circumstances. The Last-Access date (selected by /FA)
seems nearly useless for meaningful file management activities.
Original DOS file system had only 32 bytes to represent a file in
the directory. The very restrictive 8.3 filename and the limited
granularity (2 second) in file date are corrected in the Win32
file systems (VFAT). But, the generous allocation of lots of
bytes (24 bytes just to store the file date in three flavors) which
bloats the system resource usage but provides little useful
information seems to symbolize what we know as Windows Operating
© Copyright 2012 Pixelab All rights reserved.