trouble with COPY /U

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
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.
 
#2
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,100
85
#3
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
 
#4
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.
 
#5
>> 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,100
85
#6
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
 
#7
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.
 
#8
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