Hi Jochen,

We saw a similar effect. We have lots of files on the filer which are indexed by an indexing service, and at 1am (GMT) on the 26th March the indexer decided that all the files needed reindexing because all their timestamps had changed!

Our filer is in zone Europe/London.

I did a search on the NOW knowledgebase and found bug #34324, described below. I haven't had time to look into it fully (and had trouble understanding the implications anyway!) but it does look like the behaviour of the filer has been changed in recent ONTAP releases. Something to do with the filer trying to compensate for Windows behaviour when it reports timestamps. If anyone can clarify this for me too, that would be great!

http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=34324

-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Willeke, Jochen Sent: 06 April 2006 14:15 To: Glenn Walker; toasters@mathworks.com Subject: RE: Files on CIFS share have timestamp off by one hour after daylight saving

Hi,

the client and the filer both are hosted in CET timezone which is GMT +1 (Europe\Berlin in filerview) I can view the files with different clients but the result is the same. I had a look at the filer and the time is correct. But i found out something interesting.... The problem really is how windows looks at the files. If i set the date on my computer to November or back to Januar when we do not have the daylight saving the "timestamp" windows shows me is correct again.

I will have a look at MS Knowledgebase, perhaps i will find a fix for this problem.

Thanks a lot for pointing me in the right direction...

BTW: Can anybody of you see the same effect?

Jochen

-----Original Message----- From: Glenn Walker [mailto:ggwalker@mindspring.com] Sent: Thursday, April 06, 2006 2:11 PM To: Willeke, Jochen; toasters@mathworks.com Subject: RE: Files on CIFS share have timestamp off by one hour after daylight saving

What are you viewing the timestamps with? What timezone is that machine in? What timezone is the filer in?

My guess: when the client wrote the files, it did so with the filer's timestamp (based on the clock on the filer). When the client reads the timestamp back, it adjusts based on the difference - ie, if the file timestamp is stored in GMT (non-daylight savings time) and the client suddenly adjusts its clock, then it has to calculate for an extra hour. So the only way I could see this happening is if the clock rolled forward on the client (or adjusted on the filer too) but the savings time wasn't included in the calculation.

Check the clocks... start there.

Glenn

-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Willeke, Jochen Sent: Thursday, April 06, 2006 6:57 AM To: toasters@mathworks.com Subject: Files on CIFS share have timestamp off by one hour after daylight saving

Hi everybody,

i have a case of one user who stored some files from his Windows2000 client onto a CIFS share on a fas3050 with Ontap 6.5.4. When he first copied the files onto the share the creation time was 10:00 o'clock. This was the Friday before we had the daylight saving change. On next monday the creation time was not 10:00 but 11:00.

I have no clue how this could happen. Anybody got an idea? I would be glad even if i get some information about how timestamps are created so i can make a research myself.

Thanks a lot for any suggestions in advance

Jochen

______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

------------------------------------------------------------------------------------

Watch Public Information Films including "Charley Says"

http://www.nationalarchives.gov.uk/films/1964to1979/filmindex2.htm

-----------------------------------------------------------------------------------

National Archives Disclaimer

This email message (and attachments) may contain information that is confidential to The National Archives. If you are not the intended recipient you cannot use, distribute or copy the message or attachments. In such a case, please notify the sender by return email immediately and erase all copies of the message and attachments. Opinions, conclusions and other information in this message and attachments that do not relate to the official business of The National Archives are neither given nor endorsed by it.

------------------------------------------------------------------------------------