Kien This subject is one dear to my heart since I was the first person to report it to Tivoli. See my entry on the list 24/10/2000.
I had it in mind that 3.7.2.17 was the first version that fixed the problem but since this was replaced by 3.7.2.18 pretty quickly you should assume that 3.7.2.18 or later is where you need to be. I believe that turning off automatic adjustment will bring on the problem immediately for the next backup. The reasons for this are well documented but here's my attempt. The timestamps of files on NTFS partitions as displayed in Explorer, etc, are calculated from the UTC timestamp of the file (which is constant) and the current active time bias based on the daylight savings settings (which changes in the spring and autumn). The bug in TSM was that it was using the same calculation and perceived a change in the timestamp of the file which necessitated it being backed up. My guess is that you could work around the problem in spring by disabling automatic adjustment for daylight savings and advancing the system time by an hour instead. The active time bias (visible on NT in the registry value HKLM\System\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias) wouldn't alter and TSM would not notice any change. It's much harder in the autumn to maintain the same active time bias beyond the end of the daylight saving period. Turning off automatic adjustment for daylight savings changes prior to the end of daylight savings will just change the active time bias sooner. One thing to consider if you absolutely can't upgrade is to change the rules for daylight savings to extend it by a few days/weeks/months. For NT you can do this using the Resource Kit utility TZEDIT.EXE. Once you've redefined the rules for your time zone so that daylight savings ends in, say, December, change your time zone to something else, apply the changes and then immediately change it back to your modified version. This should ensure that the active time bias remains constant until you've had time to put something better in place. Obviously you'll have to retard the time manually on the client to achieve the adjustment in October and be aware of any issues with time synchronisation from external sources. I must stress that I've never tried this and would strongly recommend upgrading the clients as a more reliable method. Neil The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House Halifax Road Bradford BD6 2SZ Registered in England and Wales No 2366682
