Bug Report - DST bug from NTFS to EXT3

[twoj]

Hi

I've recently purchased a DS409+, mainly for backup but i'm pleased with all the other functionality so far. I am backing up from windows NTFS volumes to the DS409+ which as i understand the disks are formated into EXT3. I do several checks on the data transfered so i was a bit suprised that when i compared the copied data that there were a few files that were different. What happens is that files that were modified during the 1 hour Daylight Savings Time changeover date, that have a modified time of 2:00:00 AM to 2:59:59 AM are copied from the NTFS volume to the DS409+ and are saved with a one hour difference timestamp, ie 1:00:00 AM to 1:59:59 AM.

I beleive the bug is easy to reproduce, i created a text file on a windows ntfs volume, change the modified date to March 11 ,2007 (11/03/2007) at say 02:30:00 AM, i have a freeware program called 'Attribute Changer' to modify the dates & time. Then copy the file to the DS. It should record the timestamp as 01:30:00 AM. Obviously the problem is DST related so for reference i am in the EST (GMT -5) so it may be necessary to have that reference.

Another date i had a problem with is April 03 2005 (03/04/2005) again only between 2-3AM, which is the DST changeover time.

While it isn't a big deal to modify the files so they are not in the 2-3 am range, i think its important to keep the original timestamp. The files themselves are copied fine its just the timestamps that are altered.

Would apprciate if this can be confirmed.

Thanks

[doktor.notor]

There's no way to solve this properly, sorry. This is a Windows feature (yeah, Microsoft claims it's a feature) how it deals with DST changes and timestamps.

Explanation #1.
Explanation #2

To quote MS directly - KB158588

This behavior occurs because of the way that Windows NT stores time/date stamp information. All time/dates displayed in Event Log events and files on NTFS partitions are computed as offsets to UTC (which is the same as Greenwich Mean Time [GMT]). When you select your time-zone from the Control Panel Date/Time applet, you are setting the value for UTC. The appropriate number of hours are then added or subtracted to/from the stored UTC value. This adjusted time is then displayed in any operation which reports local time.

Now, how it works on Linux (excerpt from Explanation #1):

For example, if I create a file on June 3rd, at 3:00PM local time, the timestamp on the file will always be June 3rd, 3:00PM local time regardless of daylight savings time. The time is internally saved as seconds from epoch, which can consistently be converted to GMT time.

This is a CANTFIX really.

Finally - strongly avoid running backups during DST changes - the results can differ from software to software and may be totally unexpected. That's what we get for messing with proper time.

[twoj]

The great thing about standards is that there are so many to choose from!

Being an engineer who has spent time coding processors and microcontrollers i apprciate the information and understand the difference, at the same time i don't believe there can't be some mechanism put in place to correct this. While i am no expert on how the exchange occurs for transferring files, i'm guessing the problem is that if the DS recieves a file from a Linux (EXT3) the timestamp would be correct, while from the Windows (NTFS) it wouldn't be correct. and how would the ds know... I think that is the crux.

Its not that i run backups during DST changes - its that i have several years of data getting backed up and that i do a filesize & timestamp comparison of the orginal & backuped versions, and thats when i noticed the issue.

Although as i said the engineering side of me hates having issues like this, the practical side says 30mins of changing DST problem files will probably be a more practical solution.

However i do think that since this is a known limitation there should be some sort of publication or notice that the issue exists between windows (ntfs) and any nas that uses ext3 - i agree its not a too common problem but it seems to be an issue that has affected a fair number.

Thanks for the reply and information