summer time problem in backups

hello, using Vistas, XPs, on my source PC. With Summer time, time of the
files shifts forward for one hour.

On my backup disks (virtual truecrypt, fat32 flash, etc.disks) remains one
hour late.

How to resolve backup problem? Comparing time shows, that all files on
source is one hour newer.

Thank you for replies.
--
regards,
Jiri Cvrk (Prague, Czech.rep)
http://cvrk.com/indexe.htm

One hour should not be a big deal.
The moment of time change is specially chosen to be
at night, when most normal people do something else rather than updating
their files

Technically, on FAT disks the file times are local, for compatibility
reason. On NTFS disks, file times are UNC, so they are independent
of the time zones. Use NTFS or other filesystem that stores times as UNC.


-- pa

Jiøí Cvrk wrote:
> hello, using Vistas, XPs, on my source PC. With Summer time, time of the
> files shifts forward for one hour.
>
> On my backup disks (virtual truecrypt, fat32 flash, etc.disks) remains
> one hour late.
>
> How to resolve backup problem? Comparing time shows, that all files on
> source is one hour newer.
>
> Thank you for replies.
> --
> regards,
> Jiri Cvrk (Prague, Czech.rep)
> http://cvrk.com/indexe.htm

>"Pavel A." <> pí¹e v diskusním pøíspìvku
>news:%...
>One hour should not be a big deal.

he? It is a very big problem, this feature can indicate, that older files
are newer, than actual source during backup. Your new sources can be
overwritten.




>The moment of time change is specially chosen to be
>at night, when most normal people do something else rather than updating
>their files



>Technically, on FAT disks the file times are local, for compatibility
>reason. On NTFS disks, file times are UNC, so they are independent
>of the time zones. Use NTFS or other filesystem that stores times as UNC.

We must use fat32 for compatibility reason for backup. In the morning after
time change all old photographs token during years indicate that new backup
is necessary. Old program sources too.

Not any serious answer in the whole community??





Jiøí Cvrk wrote:
> hello, using Vistas, XPs, on my source PC. With Summer time, time of the
> files shifts forward for one hour.
>
> On my backup disks (virtual truecrypt, fat32 flash, etc.disks) remains one
> hour late.
>
> How to resolve backup problem? Comparing time shows, that all files on
> source is one hour newer.
>
> Thank you for replies.
> --
> regards,
> Jiri Cvrk (Prague, Czech.rep)
> http://cvrk.com/indexe.htm

In message <832E2DA7-6903-4864-93AD-> Ji?í
Cvrk <> was claimed to have wrote:

>>"Pavel A." <> píše v diskusním p?ísp?vku
>>news:%.. .
>>One hour should not be a big deal.
>
>he? It is a very big problem, this feature can indicate, that older files
>are newer, than actual source during backup. Your new sources can be
>overwritten.

If your backup software is a two-way sync and it can't handle DST then
you should shut it down for an hour during the DST switchover.

>We must use fat32 for compatibility reason for backup. In the morning after
>time change all old photographs token during years indicate that new backup
>is necessary. Old program sources too.
>
>Not any serious answer in the whole community??

I'd suggest upgrading or replacing whatever backup software you're
using, it's obviously deficient in this area and since DST NTFS vs FAT
differences have been known since the beginning of NTFS.

it is not only a question of backups,
today I met my customers with linux server, I connected to samba and see,
compare directories in TotalCommander and .. that they have all programs one
hour older.
--
regards,
J.Cvrk


"Dave Warren" <dave-> píse v diskusním príspevku
news:...
> In message <832E2DA7-6903-4864-93AD-> Ji?í
> Cvrk <> was claimed to have wrote:
>
>>>"Pavel A." <> píse v diskusním p?ísp?vku
>>>news:%. ..
>>>One hour should not be a big deal.
>>
>>he? It is a very big problem, this feature can indicate, that older files
>>are newer, than actual source during backup. Your new sources can be
>>overwritten.
>
> If your backup software is a two-way sync and it can't handle DST then
> you should shut it down for an hour during the DST switchover.
>
>>We must use fat32 for compatibility reason for backup. In the morning
>>after
>>time change all old photographs token during years indicate that new
>>backup
>>is necessary. Old program sources too.
>>
>>Not any serious answer in the whole community??
>
> I'd suggest upgrading or replacing whatever backup software you're
> using, it's obviously deficient in this area and since DST NTFS vs FAT
> differences have been known since the beginning of NTFS.

Jirí Cvrk wrote:
> it is not only a question of backups,
> today I met my customers with linux server, I connected to samba and
> see, compare directories in TotalCommander and .. that they have all
> programs one hour older.
> --
> regards,
> J.Cvrk

Maybe one if you has the time set incorrectly:
the local time shifted to 1 hour rather than set correct
time zone & DST. Other options:
- Compare with software that allows to specify time offset (is there a
TC plugin for this?)
- Fix the times on the affected files. (The linux folks know how to
use touch command).

--pa


> "Dave Warren" <dave-> píse v diskusním príspevku
> news:...
>> In message <832E2DA7-6903-4864-93AD-> Ji?í
>> Cvrk <> was claimed to have wrote:
>>
>>>> "Pavel A." <> píse v diskusním p?ísp?vku
>>>> news:%...
>>>> One hour should not be a big deal.
>>>
>>> he? It is a very big problem, this feature can indicate, that older
>>> files
>>> are newer, than actual source during backup. Your new sources can be
>>> overwritten.
>>
>> If your backup software is a two-way sync and it can't handle DST then
>> you should shut it down for an hour during the DST switchover.
>>
>>> We must use fat32 for compatibility reason for backup. In the morning
>>> after
>>> time change all old photographs token during years indicate that new
>>> backup
>>> is necessary. Old program sources too.
>>>
>>> Not any serious answer in the whole community??
>>
>> I'd suggest upgrading or replacing whatever backup software you're
>> using, it's obviously deficient in this area and since DST NTFS vs FAT
>> differences have been known since the beginning of NTFS.
>