Re: Bug In NTFS Date/Time in Windows XP SP3 Fully Patched

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



"Bill Blanton" wrote:

"odp" <odp@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:CCB5DE22-BB7D-40F0-BA42-029E2681A03D@xxxxxxxxxxxxxxxx
"John Wunderlich" wrote:

Stewart Berman <saberman@xxxxxxxxxxxxx> wrote in
news:4q49r45d599v53ole53fqsrtsnrr1q3gtu@xxxxxxx:

You are correct -- the USB drive does have a FAT32 file system not
NTFS. However, it is still a bug. If I modified a file at 1:15
AM on the 23rd of February it should show that time even if it is
the 8th of March. Otherwise the audit trail is not reliable.

On a NTFS-formatted drive, the file date is physically stored in UTC
time. There is no daylight savings time here. It is strictly GMT. The
file date/time is fixed. What does change is how time is _displayed_.
If you tell Windows you want the time displayed as Pacific Daylight
Time, then the system will subtract 7 hours from the actual recorded
time and show you that. It only _appears_ to shift by one hour because
you implicitly tell Windows that you want it displayed as Daylight time
instead of Standard time. The file date/time itself is recorded on
disk in GMT and does not change, thus 'audit trail' is physically
unbroken.

I have had the same problem, between my NTFS internal hard disk, and my
FAT32 esternal hard disk. You answer was very explanatory. You say that

On a NTFS-formatted drive, the file date is physically stored in UTC
time. There is no daylight savings time here. It is strictly GMT. The
file date/time is fixed. What does change is how time is _displayed_.

What has confused me is that when time switched from ST to DST, why were the
timestamps on all of my internal hard disk files changed at all? All that
needed to change was the system clock time, so that when "new" files are
created or old files "modified" they will have the correct "current"
timestamp. None of the pre-existing files were modified - so why were their
timestamps altered? Files need to "display" the true create/modify
timestamp, and not display create/modify time adjusted for current time. If
I go and talk with someone about changing a file, I need to remember if it
was changed during ST or DST, so I can adjust in my mind, what hour I should
ask about? Even if both the FAT32 and NTFS file systems changed the files
the same - to my lights it would still not be accurate. How can we keep
accurate date and timestamps, if ms just comes in and willy nilly changes
them?

The point is that the timestamp did not change. Just the "displayed time".

I understand the point. I may not have written it clearly, when I wrote
'changed' what I meant to write, was "displayed'. Even if the FAT32 and
NTFS file systems both displayed in sync using DST, why would we want files
created on 1/1/2006 at noon to display 1/1/2006 01:00 pm? One pm is not the
'true' time it was created.

Fiels created prior to the DST change should not display differently after
the switch. The new DST system time can be used to reflect timestamps for
new files and files moidfied after the switch. Am I the only one who thinks
this is a screwy way to treat files?
.

Relevant Pages

  • Re: Bug In NTFS Date/Time in Windows XP SP3 Fully Patched
    ... I have had the same problem, between my NTFS internal hard disk, and my ... timestamps on all of my internal hard disk files changed at all? ... and not display create/modify time adjusted for current time. ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Bug In NTFS Date/Time in Windows XP SP3 Fully Patched
    ... I have had the same problem, between my NTFS internal hard disk, and my ... timestamps on all of my internal hard disk files changed at all? ... and not display create/modify time adjusted for current time. ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: errors reading linked table when row contains Timestamp
    ... read timestamps, it should be fine. ... > the ten-thousandths, hundred-thousandths, and millisecond positions ... > Ill-affected rows display as #Deleted in all columns if using ... > in DB2 with. ...
    (microsoft.public.access.conversion)
  • Re: Fedora OS display and NTFS mount problems !
    ... Betreff: Re: Fedora OS display and NTFS mount problems! ... but do truly need some help in Fedora OS. ... Second question is about mounting NTFS under Fedora Core 5 for my AMD ...
    (Fedora)
  • Re: Fedora OS display and NTFS mount problems !
    ... Betreff: Re: Fedora OS display and NTFS mount problems! ... but do truly need some help in Fedora OS. ... Second question is about mounting NTFS under Fedora Core 5 for my AMD ...
    (Fedora)