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
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
