Re: [sleuthkit-users] FAT filesystem timestamp confusion
Brought to you by:
carrier
From: Brian C. <ca...@sl...> - 2003-04-03 22:29:30
|
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 |