Ext3 users - Jun 2009 - [Q] What might cause modification dates to shift later by an hour?

Recently, our backup software oddly decided to rebackup a good 
portion of our file server instead of just doing an incremental. When 
I examined various sets of presumably identical files, I discovered 
that the modification dates on these files were no longer the same. 
Many files were re-dated to exactly one hour later such that if a 
file had been modified on 3/24/04 at 2:24:53 PM, it's modification 
date had somehow been changed to 3/24/04 at 3:24:53 PM.

A point to note that is that this server is actually two separate 
servers with independent storage mirrored by drbd. And it's possible 
that the first backup was done on one server and the second on the 
other. However, drbd mirrors the storage bit by bit, so it's hard to 
see how files on each of them could have different modification 
dates. Also, even if the time on the computers were different by an 
hour (they're current the same to the second), it's not clear how the 
modification dates could somehow get re-dated.

It's also not clear what mechanism could have redated them. I've 
almost certainly run fsck on the affected filesystems. Would there 
ever be a circumstance when fsck might second guess a file's 
modification time and change it? e2fsck is currently 1.41.4, though I 
don't know if that's the version that I ran when I ran it.

However, there seems to be a field in the backup software called 
status modification date and a lot of these affected files had their 
status modified around the same time, implying something did iterate 
over the files and do something to them.
-- 

Maurice Volaski, mvolaski at aecom.yu.edu
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University

Time zones are the culprit -- Specifically DST shifts.
If you check the absolute time stamp (which is GMT), it hasn't changed...
but the distance between you and GMT changed by one hour when the DST change
kicked in.
Nothing has gone wrong, unless your backup software works internally with TZ
shifted date stamps, in which
case it might get confused twice per yer.


On Thu, Jun 25, 2009 at 11:29 AM, Maurice Volaski <mvolaski at
aecom.yu.edu>wrote:
> Recently, our backup software oddly decided to rebackup a good portion of
> our file server instead of just doing an incremental. When I examined
> various sets of presumably identical files, I discovered that the
> modification dates on these files were no longer the same. Many files were
> re-dated to exactly one hour later such that if a file had been modified on
> 3/24/04 at 2:24:53 PM, it's modification date had somehow been changed
to
> 3/24/04 at 3:24:53 PM.
>
> A point to note that is that this server is actually two separate servers
> with independent storage mirrored by drbd. And it's possible that the
first
> backup was done on one server and the second on the other. However, drbd
> mirrors the storage bit by bit, so it's hard to see how files on each
of
> them could have different modification dates. Also, even if the time on the
> computers were different by an hour (they're current the same to the
> second), it's not clear how the modification dates could somehow get
> re-dated.
>
> It's also not clear what mechanism could have redated them. I've
almost
> certainly run fsck on the affected filesystems. Would there ever be a
> circumstance when fsck might second guess a file's modification time
and
> change it? e2fsck is currently 1.41.4, though I don't know if
that's the
> version that I ran when I ran it.
>
> However, there seems to be a field in the backup software called status
> modification date and a lot of these affected files had their status
> modified around the same time, implying something did iterate over the
files
> and do something to them.
>

-- 
Stephen Samuel http://www.bcgreen.com  Software, like love,
778-861-7641                              grows when you give it away
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/ext3-users/attachments/20090625/e5cec9c7/attachment.htm>

One easy workaround would be to, when you start the backup program, to set
it to a timezone that does not have  daylight savings time shifts.  (eg: "
TZ=MST  run_my_backup"  )

This can be done on a per-process (or per-user) basis by setting the TZ
environment  variable before
starting the process (or in a user's .*profile file)

On Fri, Jun 26, 2009 at 3:00 PM, Maurice Volaski <mvolaski at
aecom.yu.edu>wrote:
> Time zones are the culprit -- Specifically DST shifts.
>> If you check the absolute time stamp (which is GMT), it hasn't
changed...
>> but the distance between you and GMT changed by one hour when the DST
>> change kicked in.
>> Nothing has gone wrong, unless your backup software works internally
with
>> TZ shifted date stamps, in which
>> case it might get confused twice per yer.
>>
>>  Thanks for you answer. It looks like a bug in the backup software.
>
-- 
Stephen Samuel http://www.bcgreen.com  Software, like love,
778-861-7641                              grows when you give it away
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/ext3-users/attachments/20090626/8da87806/attachment.htm>