Hello All,

I've got a bit of a problem : I'm backing-up files to a networked drive,
and have got time-zone and/or summer/winter-time issues.

My working computer is at GMT+1, and changes its clock depending on
summer/winter-time. The networked drive is setto GMT+0 and does not
(automatically) switch.

The end-result is that, when my computer adjust for summer/winter-time the
files on it suddenly look an hour older or newer, making my backup-program
to ignore files created the last hour, or to write *every file* created in
winter-time again to the networked drive.

Below is the result of a check of a file that has been backed up in
winter-time, and the computer has since switched over to summer-time.

-- file on network-storage
CT: 01C869E208218900 - 080207 23:34:50
LA: 01C75B0D03CFC900 - 070228 07:49:46
LW: 01C75B0D03CFC900 - 070228 07:49:46 <----

-- file on local storage
CT: 01C75C312566DE80 - 070301 18:40:55
LA: 01C8A3FB0B31F000 - 080421 22:00:00
LW: 01C75B04A20B6100 - 070228 06:49:46 <----

(CT=Current time, LA=Last accessed, LW=Last written).

After all this explaining here is my question :

How *does* a "normal" backup-program (writing to another computer) deal with
this (which method does it use) ?

As a possibble solution : Is there any way in which I can tell the standard
file-copy function (CopyFile, kernel32) to use GMT instead of local time ?

Regards,
Rudy Wieser

On Apr 22, 3:17*am, "R.Wieser" <addr...@not.available> wrote:

Hi,

Normally you would synchronize the network with the server's
time of day information, the following API can help you do that:

NetRemoteTOD()

http://msdn2.microsoft.com/en-us/library/aa370612.aspx

http://technet2.microsoft.com/Window...6e2101033.mspx

Kellie.

On Tue, 22 Apr 2008 12:17:59 +0200, "R.Wieser" <address@not.available>
wrote:


I don't have a direct answer to your question. But you can compare the
times yourself and then decide whether to call CopyFile. My
documentation for the FILETIME structure says it contains UTC. So you
can use GetFileTime to get the last write time for each file, and can
compare those. Just be sure you use ULARGE_INTEGER as recommended in
the documentation for FILETIME.


-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 400
Boston, MA 02116
www.penfact.com
Useful reading (be sure to read its disclaimer first):
http://catb.org/~esr/faqs/smart-questions.html

Hello Kellie,

I'm not sure how synchronizing the local computer with the file-server
would solve the problem(s) I've described ... Could you elaborate ?

Actually, currently both the computers and file-server *are* synchronized
in regard to their basic GMT-times. The only difference is that they are
not in the same time-zone or daylight-savings rithm.

Regards,
Rudy Wieser

Kellie Fitton <KELLIEFITTON@yahoo.com> schreef in berichtnieuws
fb1a48c2-a3c6-4be5-b093-cd5e33572c29...oglegroups.com...
On Apr 22, 3:17 am, "R.Wieser" <addr...@not.available> wrote:

Hi,

Normally you would synchronize the network with the server's
time of day information, the following API can help you do that:

NetRemoteTOD()

http://msdn2.microsoft.com/en-us/library/aa370612.aspx

http://technet2.microsoft.com/Window...0-e5f7-41b3-b0
e8-240f8236e2101033.mspx

Kellie.

Hello Robert,

That is just what I'm currently doing : one "FindFirstFile" for both, which
returns the created, last accessed and last written times (along with the
file-size, which I allso use in the comparision).

Alas, the returned time for the (local) file changes when either the
time-zone or the daylight-savings time changes (hence my described problem).

Regards,
Rudy Wieser


<r_z_aret@pen_fact.com> schreef in berichtnieuws
dgbs04tj0chob5o617ihr774mq0ene086l@4ax.com...

On Apr 22, 12:40*pm, "R.Wieser" <addr...@not.available> wrote:

Hi Rudy,

Then you can use the following APIs to get information about
the time zone & daylight saving, and synchronize the file copy
back-up operation:

GetTimeZoneInformation()

GetDynamicTimeZoneInformation()

GetTimeZoneInformationForYear()

http://msdn2.microsoft.com/en-us/library/ms724421.aspx

http://msdn2.microsoft.com/en-us/library/ms724318.aspx

http://msdn2.microsoft.com/en-us/library/bb540851.aspx

Kellie.

Hello Kellie,


I've found the first, and am afraid that I do not quite understand, from
those pages, what those two others do. The second one seems to do the same
as the first, and the third I have no clue what it even means to do : a
specific time-zone for a certain *year* ?

I allso have the problem that I do not really know which changes the local
time-zone settings make to the file-times. I tried to subtract, from the
FindFirstFile call's Last-written time for the local file, the apropriate
(negative) value from the GetTimeZoneInformation() call (the file-server has
been set to GMT to not have time-adjustment problems from there too), but
some files seemed not to be adjusted correctly.

I'm trying to make sense of the results I'm getting, but have a hard time
doing so (hence my initial question).

Regards,
Rudy Wieser


Kellie Fitton <KELLIEFITTON@yahoo.com> schreef in berichtnieuws
07b715e5-b262-4931-96a1-d361c19ecb1a...oglegroups.com...
On Apr 22, 12:40 pm, "R.Wieser" <addr...@not.available> wrote:

Hi Rudy,

Then you can use the following APIs to get information about
the time zone & daylight saving, and synchronize the file copy
back-up operation:

GetTimeZoneInformation()

GetDynamicTimeZoneInformation()

GetTimeZoneInformationForYear()

http://msdn2.microsoft.com/en-us/library/ms724421.aspx

http://msdn2.microsoft.com/en-us/library/ms724318.aspx

http://msdn2.microsoft.com/en-us/library/bb540851.aspx

Kellie.

On Apr 23, 1:27*am, "R.Wieser" <addr...@not.available> wrote:

Hi Rudy,

The API GetTimeZoneInformation() will get the time zone settings
and help you determine whether or not the daylight saving is in
effect.
The returned value TIME_ZONE_ID_DAYLIGHT indicates the system is
operating in the range covered by the DaylightDate member.

Since the timezone in your working computer is set at GMT + 1, you
will
need to do additional calculation to compensate for the fact that GMT
is
adjusted for daylight saving time (in Windows), UTC is not.

So, if you want the local time, you can use the following API to
convert
the FileTime (UTC) to a FileTime (local):

FileTimeToLocalFileTime()

Also,

SystemTimeToTzSpecificLocalTime()

http://msdn2.microsoft.com/en-us/lib...77(VS.85).aspx

http://msdn2.microsoft.com/en-us/library/ms724949.aspx

Kellie.

On Tue, 22 Apr 2008 21:47:36 +0200, "R.Wieser" <address@not.available>
wrote:

That's not quite what I suggested. They should be the same, but just
to be sure, you might try calling GetFileTime to see whether it and
FindFirstFile return different values.

That sure doesn't sound like UTC. So I misread the documentation for
the FILETIME structure and/or the documentation is wrong.


-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 400
Boston, MA 02116
www.penfact.com
Useful reading (be sure to read its disclaimer first):
http://catb.org/~esr/faqs/smart-questions.html

On Apr 22, 8:47*pm, "R.Wieser" <addr...@not.available> wrote:
Is your local file system FAT or NTFS? MSDN says this: "The NTFS file
system stores time values in UTC format, so they are not affected by
changes in time zone or daylight saving time. The FAT file system
stores time values based on the local time of the computer.":

http://msdn2.microsoft.com/en-us/library/ms724290.aspx

Using an NTFS volume may solve your problem, but of course that may
not be practical.

Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
P.S. I suggest you ignore the annoying Kelliebot!

Hello Richard,

My local system is Fat32. For the remote system it probably does not
matter, as I've (currently) put it in a GMT+0 and no daylight-savings mode.

Alas, that info does not help either. Although they make it sound that
GetFileTime behaves, for its times, differently from FindFileFirst, a test
revealed that both show the same for three different files (old on local,
old on remote, new on remote).

There *must* be a way to counter-act Windows quirkyness for FAT-drives, most
backup programs seem to work without problems ... :-\

Regards,
Rudy Wieser


Richard Russell <news@rtrussell.co.uk> schreef in berichtnieuws
b7252426-a3f4-4efe-a941-161782ee6091...oglegroups.com...
On Apr 22, 8:47 pm, "R.Wieser" <addr...@not.available> wrote:

Is your local file system FAT or NTFS? MSDN says this: "The NTFS file
system stores time values in UTC format, so they are not affected by
changes in time zone or daylight saving time. The FAT file system
stores time values based on the local time of the computer.":

http://msdn2.microsoft.com/en-us/library/ms724290.aspx

Using an NTFS volume may solve your problem, but of course that may
not be practical.

Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
P.S. I suggest you ignore the annoying Kelliebot!

Hello Robert,

I just tested for a old local, old remote, and new remote file. All
returned Last-write times (the one I need to use) are the same for both.

But I got a brain-fart and checked the time the file-explorer would show for
the old local file. Currently the time FileFindFirst returns is two hours
before the time the file-explorer shows. This difference matches the
(currently effective for my country) GMT+1 +summer-time (one hour)
time-offset.

It allso checks-out with some other info I've got, being that the UTC time
is calculated from the local time which the time-offsets (GMT & summer-time)
are subtracted from (that clarifies why the time-offsets in the
GetTimeZoneInformation are *negative*, not positive)

I'm going to see if I can use the GetTimeZoneInformation to find-out the
local files time-zone (at time of last-write) and un-add the Summer-time
difference back to such a file.

Regards,
Rudy Wieser


<r_z_aret@pen_fact.com> schreef in berichtnieuws
541v0456cthkqncohpan166m8iecb1vfi2@4ax.com...

Well, I got some code running that counter-acts the local filetime to (MS
idea of) UTC conversion, and than a *real* local filetime to UTC (GMT+0)
conversion.

Alas, although now the remote file gets the correct UTC, displaying files
from that file-server now makes them appear to saved one hour later than the
local file. This due to the same (brain-dead) MS time-conversion, but now
in the reverse. :-(

It looks like I'm stuck, unless someone has got an idea to solve it, with
saving the file using the incorrect localtime-to-UTC conversion, and ignore
any time-differences with the file if its less-or-equal than an hour (the
difference between summer and winter-time).

Either that, or I need to update MS'es time-conversion routine (and I'm not
sure if that is possible or wise)

Regards,
Rudy Wieser


R.Wieser <address@not.available> schreef in berichtnieuws
481041e9$0$607$e4fe514c@dreader27.news.xs4all.nl.. .

"R.Wieser" <address@not.available> wrote in
news:48109a0c$0$3678$e4fe514c@dreader31.news.xs4al l.nl:

This may or may not help, but take a look at Raymond Chen's blog at:
http://blogs.msdn.com/oldnewthing/default.aspx

In the search box, type in "fat time." The first 4 results are probably
going to be the most relative to your problem. I doubt you'll find the
solution, but at least you'll understand the problem better.

Puckdropper
--
You can only do so much with caulk, cardboard, and duct tape.

To email me directly, send a message to puckdropper (at) fastmail.fm

Hello Puckdropper,

Alas, that page uses javascript, which is not enabled on my browser, for the
searchbox. It means that although I get a reload of the page nothing
changes. :-\

Thanks for trying though.

Regards,
Rudy Wieser


Puckdropper <puckdropper(at)yahoo(dot)com> schreef in berichtnieuws
4810f7d4$0$11194$c3e8da3@news.astraweb.com...

On Apr 25, 8:08*am, "R.Wieser" <addr...@not.available> wrote:
Try this:

http://blogs.msdn.com/oldnewthing/se...q=FAT+time&p=1

Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.

In article <48103ef2$0$7125$e4fe514c@dreader25.news.xs4all.nl >,
address@not.available says...

[ ... ]

Irrelevant -- backup programs normally don't base their decisions on
time stamps at all. Instead, they look only at the file's archive bit. A
file's archive bit is set any time you write the file. A normal backup
program will clear the bit when it backs up the file. Virtually nothing
else ever clears the archive bit. Therefore, the bit being set indicates
(fairly reliably) that the file needs to be backed up because it has
been changed since the last time it was backed up.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Hello Jerry,

:-) Yes, I considered taking a look at that attribute-bit as well. But I
decided against it, as I would like to have a bit more *dependable* method
than that one. Just a quick attrib +/-a /s would wreak havoc to that
scheme. And that is ignoring the possibility some *other* software could
be depending on it/is mucking around with it.

Thanks for the suggestion though.

Regards,
Rudy Wieser



Jerry Coffin <jcoffin@taeus.com> schreef in berichtnieuws
MPG.228cadbf205df3d7989ca8@news.sunsite.dk...

Jerry Coffin wrote:
Actually, high end backup systems, such and EMC's Legato Networker and
Symantec's Vertias Netbackup, which come from the Unix world _do_ use
timestamps to determine what to backup. They have to; the Unix file
system has not "archive" bit.

And this turns out to be a very good thing because several storage
system manufacturers offer "snap shot" features which make a
point-in-time image of storage devices available to a separate backup
server while the production server goes on about its business. If the
backup server simply cleared the archive bit in the snap shot image,
that change would be lost when the snap shot was eventually discarded
and the bit would still be set the next time a snap shot was taken.

To the OP: The reason that backup software can handle the "quirkiness"
of file system times is that they do not compare the timestamps on two
copies of the file; they capture the timestamp in a database when they
back up the file and during the next backup cycle they compare the
file's timestamp to that in the database.

--
Norm

To reply, change domain to an adult feline.

In article <sMCdnT3tqL97eLnVnZ2dnUVZ_j-dnZ2d@earthlink.com>,
norm@BlackKittenAssociates.com says...

[ ... ]

Right -- my point wasn't so much that backup systems _can't_ depend on
timestamps, as that a backup system can work perfectly well without
using timestamps at all (e.g. under CP/M they did exactly that).

I certainly agree that if you _are_ going to use timestamps, having them
all come from a single file system makes life drastically simpler. If
you're going to attempt a distributed system like the OP contemplates,
you're not only going to need to translate between how the file systems
interpret time, but also ensure that the clocks are _tightly_
coordinated between all the systems. Then, of course, you need to decide
what to do when you encounter a conflict -- i.e. that different copies
of the same file have been changed in different ways, so no one is
really more up-to-date than the other.

--
Later,
Jerry.

The universe is a figment of its own imagination.