trouble with COPY /U

If I run this command it works fine

E:
cd E:\intellij\j6m\src\com
copy /UF /S /E /T *.java E:\com

However, if I run it again immediately afterward, it STILL copies all the same files over again. Can anyone think of what might be causing this?

Take Command started doing this a week or so ago.

It also happens with /U and without the /E and without the /T.

I am running Vista Home premium on an NTFS partition.
 
I have done some more work on this.
I installed build 68. I wrote a utlity to dump the create/access/and last modified dates of a file accurate both to the Java ms and MS nanosecond.

I discovered that when the last modified date was identical to the ns in source and target 4NT COPY still copied.

Oddly when I used /U instead of /UF now it works. I took the docs to mean that files with in a 2 seconds slop were considered to have the same timestamp for /UF. I think there is a bug in there somewhere.
 

rconn

Administrator
Staff member
May 14, 2008
10,975
97
Roedy wrote:

> If I run this command it works fine
>
> E:
> cd E:\intellij\j6m\src\com
> copy /UF /S /E /T *.java E:\com
>
> However, if I run it again immediately afterward, it STILL copies all the same files over again. Can anyone think of what might be causing this?
>
> Take Command started doing this a week or so ago.
>
> It also happens with /U and without the /E and without the /T.
>
> I am running Vista Home premium on an NTFS partition.
Not reproducible here.

Assuming you don't have an alias for COPY, this would have to be a
Windows issue on your system. (Both the time comparison and copy are
done by Windows APIs.)

Rex Conn
JP Software
 
May 20, 2008
604
0
Sammamish, WA
I get the same problem using /UF but not with /U

TCC 10.00.68 Windows XP [Version 5.1.2600]
TCC Build 68 Windows XP Build 2600 Service Pack 3


D:\>md TEST

D:\>cd TEST

D:\TEST>echo foo > test.java

D:\TEST>*copy /UF test.java test1.java
D:\TEST\test.java => D:\TEST\test1.java
1 file copied

D:\TEST>*copy /UF test.java test1.java
D:\TEST\test.java => D:\TEST\test1.java
1 file copied

D:\TEST>*copy /U test.java test1.java
0 files copied

On Thu, May 28, 2009 at 5:06 AM, rconn <> wrote:

> Roedy wrote:
>
>
> ---Quote---
>> If I run this command it works fine
>>
>> E:
>> cd E:\intellij\j6m\src\com
>> copy /UF /S /E /T *.java E:\com
>>
>> However, if I run it again immediately afterward, it STILL copies all the same files over again. *Can anyone think of what might be causing this?
>>
>> Take Command started doing this a week or so ago.
>>
>> It also happens with /U and without the /E and without the /T.
>>
>> I am running Vista Home premium on an NTFS partition.
> ---End Quote---
> Not reproducible here.
>
> Assuming you don't have an alias for COPY, this would have to be a
> Windows issue on your system. *(Both the time comparison and copy are
> done by Windows APIs.)
>
> Rex Conn
> JP Software
>
>
>
>
>


--
Jim Cook
2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Sunday.
 
May 20, 2008
604
0
Sammamish, WA
>> Assuming you don't have an alias for COPY, this would have to be a
>> Windows issue on your system. *(Both the time comparison and copy are
>> done by Windows APIs.)
Rex:

What are you using for the time comparison?
Are you using CopyFile or CopyFileEx for the file copy?

--
Jim Cook
2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Sunday.
 

rconn

Administrator
Staff member
May 14, 2008
10,975
97
Jim Cook wrote:

> ---Quote---
>>> Assuming you don't have an alias for COPY, this would have to be a
>>> Windows issue on your system. *(Both the time comparison and copy are
>>> done by Windows APIs.)
> ---End Quote---
> Rex:
>
> What are you using for the time comparison?
> Are you using CopyFile or CopyFileEx for the file copy?
CopyFileEx for the file copy, and CompareFileTime to compare the last
write times.

Rex Conn
JP Software
 
May 20, 2008
604
0
Sammamish, WA
In my simple program, it shows the last write times compare exactly
equal according to CompareFileTime. However, COPY /UF continues to
copy the file. In fact, when I force all three times to be exactly the
same, COPY /UF continues to copy the file.

I don't see how CompareFileTime can be used to do the /UF function of
"more than 2 seconds newer" directly. You must do some interesting
manipulation instead.



#include "windows.h"
#include "stdio.h"

int main(int argc, char * argv[])
{
HANDLE hFile1, hFile2;
FILETIME ftFileC1, ftFileA1, ftFileW1;
FILETIME ftFileC2, ftFileA2, ftFileW2;

hFile1 = CreateFile(argv[1], GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL);
if (hFile1 == INVALID_HANDLE_VALUE) abort();
hFile2 = CreateFile(argv[2], GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL);
if (hFile2 == INVALID_HANDLE_VALUE) abort();

if (!GetFileTime(hFile1, &ftFileC1, &ftFileA1, &ftFileW1)) abort();
if (!GetFileTime(hFile2, &ftFileC2, &ftFileA2, &ftFileW2)) abort();

printf("C=%d A=%d W=%d\n",
CompareFileTime(&ftFileC1, &ftFileC2),
CompareFileTime(&ftFileA1, &ftFileA2),
CompareFileTime(&ftFileW1, &ftFileW2));
}


On Tue, Jun 2, 2009 at 4:52 PM, rconn <> wrote:

> Jim Cook wrote:
>
>
> ---Quote---
>> ---Quote---
>>>> Assuming you don't have an alias for COPY, this would have to be a
>>>> Windows issue on your system. *(Both the time comparison and copy are
>>>> done by Windows APIs.)
>> ---End Quote---
>> Rex:
>>
>> What are you using for the time comparison?
>> Are you using CopyFile or CopyFileEx for the file copy?
> ---End Quote---
> CopyFileEx for the file copy, and CompareFileTime to compare the last
> write times.
>
> Rex Conn
> JP Software
>
>
>
>
>


--
Jim Cook
2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Sunday.
 
May 20, 2008
3,520
3
Elkridge, MD, USA
Jim Cook wrote:
|| In my simple program, it shows the last write times compare exactly
|| equal according to CompareFileTime. However, COPY /UF continues to
|| copy the file. In fact, when I force all three times to be exactly
|| the
|| same, COPY /UF continues to copy the file.

It is my observation, too, that COPY /UF copies files of the same age.
--
Steve