This is a discussion on [Samba] DST is coming nigh - HELP! - Samba ; Tomorrow morning my Central Europe will try to steal an hour of daylight=20 by adding an extra hour at 2 am. This event will reintroduce an old but=20 trivial show-stopper for the broader use of Samba. Microsoft has, perhaps= =20 ...
Tomorrow morning my Central Europe will try to steal an hour of daylight=20
by adding an extra hour at 2 am. This event will reintroduce an old but=20
trivial show-stopper for the broader use of Samba. Microsoft has, perhaps=
intentionally, redefined the summer/winter time reckoning and just=20
acknowledged in a KB article that, yes, MS Windows don't show the correct=
time, but they show the wrong time consistently and predictably, you have=
to live with that. No intention to ever comply with international standards.
International standards are for wimps.
I've simulated the event by adding yesterday a whole day to the=20
calender of an isolated Samba domain consisting of a Samba 3.0.20b-3.1-SuSE=
server and a Windows XP Professional member client. This morning they both
show an hour later, because they think it's Sunday already.=20
I've created a local file on the client and a client's file on the=20
Samba server yesterday and named them in the format "YYYY-MM-DD HH.MM.SS".=
Today the File Explorer shows that both files have been made an hour later
than their names imply:
Name Size Type Modified on
\\p91\P\2006-03-25-16.32.25 0 KB 25-File 2006-03-25 17:32
C:\Temp\2006-03-25-16.29.51 0 KB 51-File 2006-03-25 17:29
and I could live with that, except that from within a DOS-Box as well as=20
from within a bash shell the client's file on Samba server still appear=20
to have the correct time:
C:\>dir "\\p91\P\2006-03-25 16.32.25"
2006-03-25 16:32 0 2006-03-25 16.32.25
/p$ ll "2006-03-25 16.32.25"
-rwxrw-rw- 1 c C 0 2006-03-25 16:32 2006-03-25 16.32.25
On the other hand, if I create a client's file on the Samba server now
that they think it's already tomorrow, the DOS box and the bash shell
will still see the same, correct, time
C:\>dir "\\p91\P\2006-03-26 17.14.52"
26.03.2006 17:14 0 2006-03-26 17.14.52
/p$ ll "2006-03-26 17.14.52"
-rwxrw-rw- 1 c C 0 2006-03-26 17:14 2006-03-26 17.14.52
But the File Explorer will beg to differ - it will add an hour to the
client's filestamp on the Samba server:
\\p91\P\2006-03-26-17.14.52 0 KB 52-File 03.26.2006 18:14
C:\Temp\2006-03-26-17.13.32 0 KB 32-File 03.26.2006 17:13
Sure, I can set my timezone tomorrow to Turkish TZ, EEST instead of CEST,
so that the File Explorer, the most often used tool to explore the files=20
under Windows, won't confuse the casual user, but any DOS batch file will
call my bluff. Here's what happens in File Explorer:
Name Size Type Modified on
\\p91\P\2006-03-26 18.57.38 0 KB 38-File 2006-03-26 18:57
C:\Temp\2006-03-26 18.58.41 0 KB 41-File 2006-03-26 18:58
C:\ dir "\\p91\P\2006-03-26 18.57.38"
26.03.2006 16:57 0 2006-03-26 18.57.38
/p $ ll "2006-03-26 18.57.38"
-rwxrw-rw- 1 c C 0 2006-03-26 18:57 2006-03-26 18.57.38
Is there a clean way to let the Samba server deliver the timestamp
as Windows would expect it instead of always being right ?
To unsubscribe from this list go to the following URL and read the