[Samba] Wintertime/summertime difference - Samba servers show wrong time ?

[Dragan Krnic]

When the Central European Time was last switched back to standard,
at 03:00 last Sunday, the October 30th, a process died on one of my
Windows clients with a mysterious "unknown error". When it was 
restarted it just went merrily on with its task. Luckily it wasn't 
part of a life support system.

I found out that the immediate cause was how file timestamps were
interpreted/presented by samba server as opposed to the expectations
of a Windows client.

According to this M$ Article: 

     http://support.microsoft.com/kb/129574/en-us

    "When Windows NT automatically adjusts for daylight savings time,
     the times on files on Windows NT file system (NTFS) partitions 
     and the events in the event logs are retroactively shifted by 
     one hour, even though the files and event records were created 
     before the daylight savings time change."

In other words, Linux-based Samba servers keep on showing the right
time of the day when a file was created/changed/modified/accessed
whereas Windows falsifies it by an hour retroactively. But being 
right is not enough. As much as I regret having to do it, I need a 
tweak to resynch the file times representation of my Samba servers 
with the expected and well-documented behaviour of Windows clients, 
even though it means lying through one's own teeth. 

As a matter of fact, I don't understand how this discrepancy is at
all possible!

>From what I gathered in the documentations on both sides of the
fence, Unix traditionally stamps file times (create/status change, 
modify and last read access) with a long integer (32 bits) counting 
full seconds since midnight A.M. January 1, 1970 in Greenwhich, EU, 
whereas the NT File System apparently uses a larger data type to 
count decimicroseconds (or should I say hectonanoseconds) since 
the same time of night in the said British village on January 1, 
1601, when it wants to stamp one of its own set of file times, 
creation, content alteration, MFT change or last read access.

So basically both systems keep track of time in timezone-neutral
units, different in scale and offset but essentially interchangeable
within limits, and only interpret it as a certain time of day/night 
of this or that day of one or another month/year according to the 
user's locale.

I can't imagine that an M$ SMB server (a Windows server or 
workstation) marshals anything else on the wire than the raw data 
type in the file stamp (the wrong time is in the eye of the client), 
so Samba has to be doing something wrong if the time stamp is 
perceived on the client side as not retroactively an hour earlier 
than it really was for a file which was manipulated in the interval
between 03:00 a.m. on the first Sunday of April and 03:00 a.m. of
the last Sunday of October when viewed from outside of this interval.

Please correct me if I'm wrong, but also don't hesitate to let me 
know how to fix the problem, even if it was perhaps already 
discussed in the past.

Yours truely