Enhance COPY Command

Feb 12, 2016
7
0
68
I would like you to enhance the COPY and DIR commands to o this:
COPY /UF and COPY /U should always use the Modify date in order to determine whether or not to copy a file. Sometimes when I use COPY /UF, the command copies every file in the directory tree, not just those files in the target directory that don't exist or that have an older Modify timestamp. The COPY command should be made much more robust so that this doesn't happen.
 
Last edited:
Jan 12, 2014
515
11
Switzerland, SO
@Craig T. Dedo

Why should it only copy which don't exist in the target directory? I understand it as following:

If a source file is newer than an exist destination file, copy /u SHOULD copy that. If a source file is newer more than 2 seconds than an exist destination file, copy /uf SHOULD copy that.

If you want only copying source files if the target files doesen't exist, the "/o" switch could be for you.


@vefatica

There is no default in sense of "default preference". However, "/u" or "/uf" should always use the modification time IMHO, so in this sense a clear yes.
 
Last edited:
Feb 12, 2016
7
0
68
Doesn't "/U" and "/UF" use the modification time by default?
Not in my experience. At least it is unreliable in using the Modification Date to do the comparison. In some cases in my own experience, COPY /UF copies everything, even if the file has been unchanged for years. I don;t know why this happens but it has happened to me several times in the last year.
 
Feb 12, 2016
7
0
68
@Craig T. Dedo

Why should it only copy which don't exist in the target directory? I understand it as following:

If a source file is newer than an exist destination file, copy /u SHOULD copy that. If a source file is newer more than 2 seconds than an exist destination file, copy /uf SHOULD copy that.

If you want only copying source files if the target files doesen't exist, the "/o" switch could be for you.


@vefatica

There is no default in sense of "default preference". However, "/u" or "/uf" should always use the modification time IMHO, so in this sense a clear yes.
COPY/U and COPY/UF should always use the Modification Date but in my experience they sometimes don't.
 
Jan 12, 2014
515
11
Switzerland, SO
Not in my experience. At least it is unreliable in using the Modification Date to do the comparison. In some cases in my own experience, COPY /UF copies everything, even if the file has been unchanged for years. I don;t know why this happens but it has happened to me several times in the last year.
Ahh, ok - now I understand. That's not good of course!
 
May 20, 2008
12,099
130
Syracuse, NY, USA
I did a little test which showed that it is the modified time that's used. It's a real mess so I'll write a BTM to make it accessible and post it.
 
May 20, 2008
12,099
130
Syracuse, NY, USA
In short, starting with two files with all three timestamps equal to 00:00:00, and changing the timestamps of the source file in the order (1) created, (2) accessed, (3) modified to 00:01:00, and, after each change, trying to copy with either /U or /UF, no copy would be done until the modified time is changed. The BTM is attached. I hope someone will scrutinize it to make sure I got it right.

Here are the results.

Code:
V:\test.txt:       00:00:00 00:00:00 00:00:00
V:\test\test.txt:  00:00:00 00:00:00 00:00:00

using /u ...

using /Tc00.01:00
2021-12-05 00:01:00.000  V:\test.txt
     0 files would be copied

using /Ta00.01:00
2021-12-05 00:01:00.000  V:\test.txt
     0 files would be copied

using /Tw00.01:00
2021-12-05 00:01:00.000  V:\test.txt
     1 file would be copied


V:\test.txt:       00:00:00 00:00:00 00:00:00
V:\test\test.txt:  00:00:00 00:00:00 00:00:00

using /uf ...

using /Tc00.01:00
2021-12-05 00:01:00.000  V:\test.txt
     0 files would be copied

using /Ta00.01:00
2021-12-05 00:01:00.000  V:\test.txt
     0 files would be copied

using /Tw00.01:00
2021-12-05 00:01:00.000  V:\test.txt
     1 file would be copied
 

Attachments

  • uuftest.btm
    842 bytes · Views: 74
Jan 6, 2009
7
0
I stumbled on the thread with same/similar issues -- in particular, besides the timestamp comparison writing/updating years-old files, even with the /CF switch it's copying everything even when it doesn't exist in the target --- short section illustrates...

C:\Users\Duane\D...ents\MATLAB\Work>copy /CF /N M:*.m*
...
M:\work\tryit.m => C:\Users\Duane\Documents\MATLAB\Work\tryit.m
M:\work\uazig.m => C:\Users\Duane\Documents\MATLAB\Work\uazig.m
...
M:\work\zipdistance.m => C:\Users\Duane\Documents\MATLAB\Work\zipdistance.m
202 files would be copied

C:\Users\Duane\D...ents\MATLAB\Work>

Would have copied 200 files w/o the /N switch to see what it was doing. Many of these as Craig notes above haven't been modified in years.

On top of that, a bunch of them are NOT in the target directory -- picking one at random...

C:\Users\Duane\D...ents\MATLAB\Work> dir tryit.m

Volume in drive C is Windows Serial number is 68a4:cd84
TCC: (Sys) The system cannot find the file specified.
"C:\Users\Duane\Documents\MATLAB\Work\tryit.m"
0 bytes in 0 files and 0 dirs
119,671,218,176 bytes free

C:\Users\Duane\D...ents\MATLAB\Work>

OTOTH, XCOPY seems to do do the expected...

C:\Users\Duane\D...ents\MATLAB\Work> xcopy /l /u /d /y M:*.m*
M:\work\RestrictedAwardApp.mlapp
M:\work\splitPresAwards.m
M:\work\writeBillingClassSplits.m
3 File(s)

C:\Users\Duane\D...ents\MATLAB\Work>

as those are the files I know I worked on on the remote machine that wanted back to the local...not 200 and some plus ones that I've already cleaned up or rearranged into own locations.

There undoubtedly is some underlying explanation but surely isn't what would expect to happen -- nor what want.
 

Similar threads