Re: [sleuthkit-users] FAT filesystem timestamp confusion

[Angus M. <an...@n-...>]

On Thursday 03 Apr 2003 11:29 pm, Brian Carrier wrote:
> 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

Wow! thanks for the fast reply Brian.

Setting the zone to GMT does seem to make the filesystem timestamp
consistent with the file contents, but I'd really like to know why it makes 
a difference at all on a FAT filesystem in this case. I have to give some 
initial findings to the police tomorrow and am wary of giving them 
potentially wrong info. because it could affect an alibi. (Side note, when I 
mount the image read-only and issue a ls --full-time, I notice that some 
files have an offset field of 0000 and some have +0100 - could my experience 
be an artefact of something "clever" in the Linux system I'm using ? ls on 
the files being questioned above agrees with the results of the timeline 
analysis btw)


I've also noticed a curious behaviopur with FAT12 on the latest sleuthkit 
release. Files on a floppy were written to it at 21:45BST, with the timezone 
set to GMT0BST, they show as 2:45 tomorrow in the timeline. (file writes and 
analysis done on the same machine btw)