Documentation copy /u

[fpefpe]

Hello --- just to confirm, when files are copied (or moved) with the /u (or /c) switch, the entire 64 bit value of the ntfs (file) timestamp is used? so if the timestamp of a file just differs is in the "sub second" part of the file, that would cause the files to me copied ( or not)?

 

[vefatica]

If the source and destination are both NTFS, it looks like it uses every one of those 64 bits.

v:\> echo %@fileage[f2.txt]
131789272146787914

v:\> echo %@fileage[pluggies\f2.txt]
131789272146787913

v:\> copy /u f2.txt pluggies\
V:\f2.txt =>! V:\pluggies\f2.txt
     1 file copied

v:\> echo %@fileage[pluggies\f2.txt]
131789272146787914

v:\> echo %@fileage[f2.txt]
131789275491168791

v:\> echo %@fileage[pluggies\f2.txt]
131789275491168790

v:\> move /u f2.txt pluggies\
V:\f2.txt ->! V:\pluggies\f2.txt
     1 file moved

v:\> echo %@fileage[pluggies\f2.txt]
131789275491168791

 

[vefatica]

And

v:\pluggies> echo %@fileage[f2.txt]
131789278179897159

v:\pluggies> echo %@fileage[v:\f2.txt]
131789278179897160

v:\pluggies> copy /u f2.txt ..\
     0 files copied

v:\pluggies> move /u f2.txt ..\
     0 files moved

 

[fpefpe]

thanks for the info --- this could be problematic if programs are not adding in the nano-seconds

 

[vefatica]

I first tested with TCC's TOUCH which only uses milliseconds and that's only good to one tick of the system clock (typically about 15.6 milliseconds). Then I wrote my own (in C) which made two FILETIMEs which differed by 1. That behavior is not at all normal. Even if a program uses GetSystemTimeAsFileTime to get a timestamp, that is only updated with every tick of the system clock ... typically every ~15.6 milliseconds. My current "system time adjustment" is 156003 (ten-millionths of a second). If I look at what GetSystemTimeAsFileTime gives (using my plugin _AGENOW), that's exactly the increment I see (~15.6 ms).

do forever ( echo %_agenow )
<snip>
131789451506789980
131789451506789980
131789451506789980
131789451506945983
131789451506945983
131789451506945983

 

[vefatica]

My point was that programs can't even come close to using nanoseconds. Typically they get ticks of the system clock (~15.6 milliseconds). Even using HiRes timing (which is system-wide and a bit rude) you can only get that down to 1 ms.

 

[fpefpe]

My point was that programs can't even come close to using nanoseconds. Typically they get ticks of the system clock (~15.6 milliseconds). Even using HiRes timing (which is system-wide and a bit rude) you can only get that down to 1 ms.

again -- thx for the info

 

[rps]

thanks for the info --- this could be problematic if programs are not adding in the nano-seconds

Couldn't using a time range with the copy help?
You can even specify which of the three Windows times to use.