Re: [sleuthkit-users] FAT filesystem timestamp confusion

[Brian C. <ca...@sl...>]

Angus Marshall <an...@n-...> said:
 
> The situation is this - the day in question falls during GMT time, but we're 
> now into BST. I've set the timezone in autopsy to be GB, but have discovered 
> a conflict in one of the files I'm looking at - it's a log file and the 
> application generating it has stamped the time in the file as an hour later 
> than the last write time on the file itself.
> 
> For reference, I'm running on RedHat Linux 8.0 with a clock that's firmly in 
> BST at the moment.

Angus,

First, FAT does not care about time zones.  Most file systems store the time
with respect to GMT and when the time is actually read the local OS adjusts
accordingly.  FAT just saves the time and does not care about the timezone, so
that is why you will not see a difference when you change the timezone in
Autopsy. 

That really doesn't explain the log entry time versus the file time though. 
The only thing that I can think about is that Windows does not handle day
light savings (or BST) well at all!  I sent a message about this to the
forensic tool testing list a while back.  In Windows, you can make a file
before day light savings takes effect, let the clock roll over and then check
the time again and it will be off by an hour!  Windows appears to subtract an
hour from all files during these time frames instead of just the ones during
those 6 months. (EnCase v3 does the same thing).

Therefore, I wonder if the problem is because Linux is changing the time by an
hour when it displays it, but since Windows didn't then it is having issues. 
What happens if you set the timezone to GMT (or even EST) and not one of the
timezones that changes (like EST5EDT).  Does that help?

brian