Did Miscrosoft change how it dates files?

Greetings

I have a batch file using Robocopy which is only suppose to copy
those files which are "newer" (I.e., modified) than the ones on the
drive. Usually, there is no problem. But tonight, as I go to close
up operations for the evening, it is copying far more files than
before. all tagged "newer".
Was there something magical about the shift to Daylight Savings
time which makes a source drive file dated "Jan 2 2019 10:20 AM" to
now be "newer" than the target drive file dated "Jan 2 2019 10:20
AM"?
I haven't changed "CHAR Sets.wpd" since 1996!?

I do remember something like this happening when the batchfile
correctly copied files from a flashdrive to the XP laptop, and then I
was done with the letter writing, the batchfile copied _all_ the files
just copied (but not used) back from the hardrive to the flash drive.

You'll have a great deal of difficulty convincing me that the
folks at Microsott really have an idea what they are doing.


--
pyotr filipivich
The question was asked: "Is Hindsight overrated?"
In retrospect, it appears to be.

On Sun, 10 Mar 2019 22:23:09 -0700, pyotr filipivich wrote:
Greetings

I have a batch file using Robocopy which is only suppose to copy
those files which are "newer" (I.e., modified) than the ones on the
drive. Usually, there is no problem. But tonight, as I go to close
up operations for the evening, it is copying far more files than
before. all tagged "newer".
Was there something magical about the shift to Daylight Savings
time which makes a source drive file dated "Jan 2 2019 10:20 AM" to
now be "newer" than the target drive file dated "Jan 2 2019 10:20
AM"?
I haven't changed "CHAR Sets.wpd" since 1996!?

I do remember something like this happening when the batchfile
correctly copied files from a flashdrive to the XP laptop, and then I
was done with the letter writing, the batchfile copied _all_ the files
just copied (but not used) back from the hardrive to the flash drive.

You'll have a great deal of difficulty convincing me that the
folks at Microsott really have an idea what they are doing.


The only probably cause is that the flashdrive is using FAT file system. FAT
has lower time resolution than NTFS, which is 2 seconds. So, if a file is
set to 10:20:33 AM by a software, the result would be 10:20:32 AM. CMD
doesn't show the seconds part, so if you use the file property dialog,
you'll see the difference in the seconds part.

JJ wrote:
On Sun, 10 Mar 2019 22:23:09 -0700, pyotr filipivich wrote:
Greetings

I have a batch file using Robocopy which is only suppose to copy
those files which are "newer" (I.e., modified) than the ones on the
drive. Usually, there is no problem. But tonight, as I go to close
up operations for the evening, it is copying far more files than
before. all tagged "newer".
Was there something magical about the shift to Daylight Savings
time which makes a source drive file dated "Jan 2 2019 10:20 AM" to
now be "newer" than the target drive file dated "Jan 2 2019 10:20
AM"?
I haven't changed "CHAR Sets.wpd" since 1996!?

I do remember something like this happening when the batchfile
correctly copied files from a flashdrive to the XP laptop, and then I
was done with the letter writing, the batchfile copied _all_ the files
just copied (but not used) back from the hardrive to the flash drive.

You'll have a great deal of difficulty convincing me that the
folks at Microsott really have an idea what they are doing.


The only probably cause is that the flashdrive is using FAT file system. FAT
has lower time resolution than NTFS, which is 2 seconds. So, if a file is
set to 10:20:33 AM by a software, the result would be 10:20:32 AM. CMD
doesn't show the seconds part, so if you use the file property dialog,
you'll see the difference in the seconds part.

The daylight savings time change (on FAT32) on Sunday,
might also be a problem, and cause "rampant copying" :-)
Aren't computers fun...

I think it's FAT32 that screws up and NTFS is OK ???

Paul

Paul on Mon, 11 Mar 2019 03:05:30 -0400 typed
in alt.windows7.general the following:
JJ wrote:
On Sun, 10 Mar 2019 22:23:09 -0700, pyotr filipivich wrote:
Greetings

I have a batch file using Robocopy which is only suppose to copy
those files which are "newer" (I.e., modified) than the ones on the
drive. Usually, there is no problem. But tonight, as I go to close
up operations for the evening, it is copying far more files than
before. all tagged "newer".
Was there something magical about the shift to Daylight Savings
time which makes a source drive file dated "Jan 2 2019 10:20 AM" to
now be "newer" than the target drive file dated "Jan 2 2019 10:20
AM"?
I haven't changed "CHAR Sets.wpd" since 1996!?

I do remember something like this happening when the batchfile
correctly copied files from a flashdrive to the XP laptop, and then I
was done with the letter writing, the batchfile copied _all_ the files
just copied (but not used) back from the hardrive to the flash drive.

You'll have a great deal of difficulty convincing me that the
folks at Microsott really have an idea what they are doing.


The only probably cause is that the flashdrive is using FAT file system. FAT
has lower time resolution than NTFS, which is 2 seconds. So, if a file is
set to 10:20:33 AM by a software, the result would be 10:20:32 AM. CMD
doesn't show the seconds part, so if you use the file property dialog,
you'll see the difference in the seconds part.

The daylight savings time change (on FAT32) on Sunday,
might also be a problem, and cause "rampant copying" :-)
Aren't computers fun...

I think it's FAT32 that screws up and NTFS is OK ???

Ah, so it is a "religious" thing (FAT32 vs NTFS).

Now to see if I want to go to the hassle of changing thumbdrive
formats.
--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?

On Mon, 11 Mar 2019 08:33:32 -0700, pyotr filipivich wrote:

Ah, so it is a "religious" thing (FAT32 vs NTFS).

FAT32 is irrelevant here. The 2 seconds time unit is a legacy of FAT12. So,
it's been there for a long time. FAT32 can not be a new file system format
because it needs some backward compatibilities with FAT16 and FAT12.

Now to see if I want to go to the hassle of changing thumbdrive
formats.

If you're considering it, for portable drives, consider exFAT instead of
NTFS. While you can use NTFS for portable drives, extra care must be taken.
Otherwise, you'll have higher probability of loosing some of your data.

FYI, exFAT has a 10 milliseconds resolution for file dates. NTFS has 100
nanoseconds.

JJ on Tue, 12 Mar 2019 07:45:27 +0700 typed in
alt.windows7.general the following:
On Mon, 11 Mar 2019 08:33:32 -0700, pyotr filipivich wrote:

Ah, so it is a "religious" thing (FAT32 vs NTFS).

FAT32 is irrelevant here. The 2 seconds time unit is a legacy of FAT12. So,
it's been there for a long time. FAT32 can not be a new file system format
because it needs some backward compatibilities with FAT16 and FAT12.

Now to see if I want to go to the hassle of changing thumbdrive
formats.

If you're considering it, for portable drives, consider exFAT instead of
NTFS. While you can use NTFS for portable drives, extra care must be taken.
Otherwise, you'll have higher probability of loosing some of your data.

FYI, exFAT has a 10 milliseconds resolution for file dates. NTFS has 100
nanoseconds.

Joy.

Thanks. I'll put reformatting the thumb drives on the list of
things to do after I figure out what Jar-Jar mean when he said "Mesa
cause one, two-y little bitty axadentes, huh? Yud say boom de gasser,
den crashin der bosses heyblibber, den banished."
--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?

JJ on Mon, 11 Mar 2019 13:24:59 +0700 typed in
alt.windows7.general the following:
On Sun, 10 Mar 2019 22:23:09 -0700, pyotr filipivich wrote:
Greetings

I have a batch file using Robocopy which is only suppose to copy
those files which are "newer" (I.e., modified) than the ones on the
drive. Usually, there is no problem. But tonight, as I go to close
up operations for the evening, it is copying far more files than
before. all tagged "newer".
Was there something magical about the shift to Daylight Savings
time which makes a source drive file dated "Jan 2 2019 10:20 AM" to
now be "newer" than the target drive file dated "Jan 2 2019 10:20
AM"?
I haven't changed "CHAR Sets.wpd" since 1996!?

I do remember something like this happening when the batchfile
correctly copied files from a flashdrive to the XP laptop, and then I
was done with the letter writing, the batchfile copied _all_ the files
just copied (but not used) back from the hardrive to the flash drive.

You'll have a great deal of difficulty convincing me that the
folks at Microsott really have an idea what they are doing.


The only probably cause is that the flashdrive is using FAT file system. FAT
has lower time resolution than NTFS, which is 2 seconds. So, if a file is
set to 10:20:33 AM by a software, the result would be 10:20:32 AM. CMD
doesn't show the seconds part, so if you use the file property dialog,
you'll see the difference in the seconds part.

Ah. Hadn't thought of that. Ufda.
--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?

On Sun, 10 Mar 2019 22:23:09 -0700, pyotr filipivich
wrote:


You'll have a great deal of difficulty convincing me that the
folks at Microsott really have an idea what they are doing.



One of the problems with a giant company like Microsoft is that
different groups of people work on different things. It's no so much
that the folks at Microsoft have no idea what they are doing, it's
more that the folks in group A have no idea what the folks in group B
are doing.

In alt.windows7.general, on Mon, 11 Mar 2019 08:23:06 -0700, Ken Blake
wrote:

On Sun, 10 Mar 2019 22:23:09 -0700, pyotr filipivich
wrote:


You'll have a great deal of difficulty convincing me that the
folks at Microsott really have an idea what they are doing.



One of the problems with a giant company like Microsoft is that
different groups of people work on different things. It's no so much
that the folks at Microsoft have no idea what they are doing, it's
more that the folks in group A have no idea what the folks in group B
are doing.

Then I am better than a Microsoft employee, because I have no idea what
the folks in group A or B are doing.

micky on Mon, 11 Mar 2019 19:28:51 +0200
typed in alt.windows7.general the following:
In alt.windows7.general, on Mon, 11 Mar 2019 08:23:06 -0700, Ken Blake
wrote:

On Sun, 10 Mar 2019 22:23:09 -0700, pyotr filipivich
wrote:


You'll have a great deal of difficulty convincing me that the
folks at Microsott really have an idea what they are doing.



One of the problems with a giant company like Microsoft is that
different groups of people work on different things. It's no so much
that the folks at Microsoft have no idea what they are doing, it's
more that the folks in group A have no idea what the folks in group B
are doing.

Then I am better than a Microsoft employee, because I have no idea what
the folks in group A or B are doing.

Word to the wise. Do not answer the question on the final "What
are the other parts of the team doing?" with "I have no idea." That
cost me the two points I needed for a passing grade needed in order to
pass the class for the last three credits towards my degree. As you
might have figured out, by then I was a wee bit past "burned out."

--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?

Ken Blake on Mon, 11 Mar 2019 08:23:06 -0700
typed in alt.windows7.general the following:
On Sun, 10 Mar 2019 22:23:09 -0700, pyotr filipivich
wrote:


You'll have a great deal of difficulty convincing me that the
folks at Microsott really have an idea what they are doing.



One of the problems with a giant company like Microsoft is that
different groups of people work on different things. It's no so much
that the folks at Microsoft have no idea what they are doing, it's
more that the folks in group A have no idea what the folks in group B
are doing.

Yeah. I knew some 'softies.

--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?

On Sun, 10 Mar 2019 22:23:09 -0700, pyotr filipivich wrote:

Greetings

I have a batch file using Robocopy which is only suppose to copy
those files which are "newer" (I.e., modified) than the ones on the
drive. Usually, there is no problem. But tonight, as I go to close
up operations for the evening, it is copying far more files than
before. all tagged "newer".
Was there something magical about the shift to Daylight Savings
time which makes a source drive file dated "Jan 2 2019 10:20 AM" to
now be "newer" than the target drive file dated "Jan 2 2019 10:20
AM"?

If you use the /TS option, robocopy will show you the timestamps of
the source file. When the source file is on an NTFS drive, that will
be in UTC, not your local time. (The timestamps displayed in File
Explorer are converted from the NTFS native UTC to your time zone.)

When the source file is on a FAT or FAT32 drive, native time is the
local time zone when the file was created or modified. (I can't
remember whether robocopy shows that local time, or converts it to
UTC.) That means if you create a file on a FAT32 USB stick at
10:00:00 Eastern Standard Time, and then mount it in Eastern Daylight
Time, the timestamp will show in File Explorer as 10:00:00, even
though the file was created at 9:00:00 Easter Daylight Time.

Robocopy supposedly understands the semiannual daylight-time shift,
and doesn't copy files in such cases, but I don't know how it knows.
I just make sure that I have updated my USB stick the last thing
before going to bed the night before the shift, so that even if the
timestamps are wrong the file contents are correct.

This past weekend, after the time shift, out of hundreds of Eastern
Standard Time files on my USB stick, robocooy wanted to copy exactly
four. I don't know what made those different from the others, so I
don't know if robocopy does basically compensate for DST and just
failed with these four.

There is an option in robocopy to copy the timestamp of a file
without copying the file contents. You might want to use that, come
November.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://BrownMath.com/
http://OakRoadSystems.com/
Shikata ga nai...

Stan Brown on Mon, 11 Mar 2019 12:05:59
-0400 typed in alt.windows7.general the following:
On Sun, 10 Mar 2019 22:23:09 -0700, pyotr filipivich wrote:

Greetings

I have a batch file using Robocopy which is only suppose to copy
those files which are "newer" (I.e., modified) than the ones on the
drive. Usually, there is no problem. But tonight, as I go to close
up operations for the evening, it is copying far more files than
before. all tagged "newer".
Was there something magical about the shift to Daylight Savings
time which makes a source drive file dated "Jan 2 2019 10:20 AM" to
now be "newer" than the target drive file dated "Jan 2 2019 10:20
AM"?

If you use the /TS option, robocopy will show you the timestamps of
the source file. When the source file is on an NTFS drive, that will
be in UTC, not your local time. (The timestamps displayed in File
Explorer are converted from the NTFS native UTC to your time zone.)

When the source file is on a FAT or FAT32 drive, native time is the
local time zone when the file was created or modified. (I can't
remember whether robocopy shows that local time, or converts it to
UTC.) That means if you create a file on a FAT32 USB stick at
10:00:00 Eastern Standard Time, and then mount it in Eastern Daylight
Time, the timestamp will show in File Explorer as 10:00:00, even
though the file was created at 9:00:00 Easter Daylight Time.

Robocopy supposedly understands the semiannual daylight-time shift,
and doesn't copy files in such cases, but I don't know how it knows.
I just make sure that I have updated my USB stick the last thing
before going to bed the night before the shift, so that even if the
timestamps are wrong the file contents are correct.

This past weekend, after the time shift, out of hundreds of Eastern
Standard Time files on my USB stick, robocooy wanted to copy exactly
four. I don't know what made those different from the others, so I
don't know if robocopy does basically compensate for DST and just
failed with these four.

There is an option in robocopy to copy the timestamp of a file
without copying the file contents. You might want to use that, come
November.

Thanks, I will look into that.

I'm already trying to remember the hack I had so that after it
ran, it then shut the computer off "for the night".
--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?

Stan Brown on Mon, 11 Mar 2019 12:05:59
-0400 typed in alt.windows7.general the following:
On Sun, 10 Mar 2019 22:23:09 -0700, pyotr filipivich wrote:

Greetings

I have a batch file using Robocopy which is only suppose to copy
those files which are "newer" (I.e., modified) than the ones on the
drive. Usually, there is no problem. But tonight, as I go to close
up operations for the evening, it is copying far more files than
before. all tagged "newer".
Was there something magical about the shift to Daylight Savings
time which makes a source drive file dated "Jan 2 2019 10:20 AM" to
now be "newer" than the target drive file dated "Jan 2 2019 10:20
AM"?

If you use the /TS option, robocopy will show you the timestamps of
the source file.

That it does.

Even as it updates all the files on thumbdrive G: from Thumbdrive
F: - both FAT32.

Meh. Major issue is that, knowing this, I will know to sync
thumbdrives earlier in the day, in order to not have to wait a half
hour while it updates all the files.

Now the question comes to me: what about the files on the external
hard drives, which are NTFS?

When the source file is on an NTFS drive, that will
be in UTC, not your local time. (The timestamps displayed in File
Explorer are converted from the NTFS native UTC to your time zone.)

Sigh, one more place where the softies have gotten "clever."

In the words of Zorba: Clever people and Grocers; they weigh
everything.

--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?

Stan Brown on Mon, 11 Mar 2019 12:05:59
-0400 typed in alt.windows7.general the following:

Robocopy supposedly understands the semiannual daylight-time shift,
and doesn't copy files in such cases, but I don't know how it knows.
I just make sure that I have updated my USB stick the last thing
before going to bed the night before the shift, so that even if the
timestamps are wrong the file contents are correct.

I think that is what I did Saturday night. Yep - even ran it a
second time and all that had changed were the game files.

Looping Owner at Documents C-loop

-------------------------------------------------------------------------------
ROBOCOPY :: Robust File Copy for Windows
-------------------------------------------------------------------------------

Started : Sat Mar 09 22:21:45 2019

Source : Q:\Documents\
Dest = R:\Documents\

Files : *.*

Exc Files : desktop.ini

Options : *.* /NDL /TEE /S /COPYAT /PURGE /NP /XJ /R:1 /W:1

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

Newer 5851 Q:\Documents\My Games\Beyond the
Sword\CivilizationIV.ini
Newer 5851 Q:\Documents\My Games\Beyond the
Sword\CivilizationIV.ini.bak
Newer 306 Q:\Documents\My Games\Beyond the
Sword\Logs\init.log
Newer 7556 Q:\Documents\My Games\Beyond the
Sword\Logs\PythonErr2.log
Newer 0 Q:\Documents\My Games\Beyond the
Sword\Logs\resmgr.log
Newer 483 Q:\Documents\My Games\Beyond the
Sword\Logs\xml.log

[Snippage ]
New File 698748 Q:\Documents\My Games\Beyond the
Sword\Saves\single\Julius R302A AD-1714 ASB End.CivBeyondSwordSave
Newer 1.1 m Q:\Documents\My Games\Beyond the
Sword\Saves\WorldBuilder\WBQuickSave.CivBeyondSwor dWBSave

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

Total Copied Skipped Mismatch FAILED Extras
Dirs : 680 650 30 0 0 0
Files : 128 13 115 0 0 31
Bytes : 83.86 m 4.91 m 78.94 m 0 0 9.74 m
Times : 0:00:03 0:00:00 0:00:00 0:00:02


Speed : 5794775 Bytes/sec.
Speed : 331.579 MegaBytes/min.

Ended : Sat Mar 09 22:21:48 2019


This past weekend, after the time shift, out of hundreds of Eastern
Standard Time files on my USB stick, robocooy wanted to copy exactly
four. I don't know what made those different from the others, so I
don't know if robocopy does basically compensate for DST and just
failed with these four.

There is an option in robocopy to copy the timestamp of a file
without copying the file contents. You might want to use that, come
November.

As I have multiple backups, I can play with them till I either
runout or it is November.
--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?