Copying the newest file from three directories

[John Gray]

Someone posed the problem of wanting to copy the newest file from out of three directories into a fourth directory, and I thought of a number of ways of doing this. The one I settled on was to set up an intermediate directory, and copy the newest file from each of the three source directories to it, then copy the newest of the three files from the intermediate directory to the target directory. This avoids messing with date and time stamps across locales.

I'd be interested if someone can think of a better/faster way of doing this.

My code was:

@echo .off
CLS
:: copy the newest file in each of three source folders
:: into an intermediate folder
:: then from the intermediate folder, copy the newest
:: of the three copied files into a target folder

setlocal

:: folder names - replace as appropriate
set sourcea=F:\Dan09\SourceA
set sourceb=F:\Dan09\SourceB
set sourcec=F:\Dan09\SourceC
set intermed=F:\Dan09\$$temp$$
set target=F:\Dan09\Target

:: set up the intermediate folder
rd %intermed% /q /s 2>nul
md %intermed%

:: find the newest file in each of the source folders
:: and copy each to the destination folder
set dest=%intermed%
for %%a in (%sourcea% %sourceb% %sourcec%) do call :copynewest %%a

:: find the newest file in the intermediate folder
:: and copy to the target folder
set dest=%target%
call :copynewest %intermed%

:: tidy up by deleting the intermediate folder
rd %intermed% /q /s

endlocal
goto :eof
::--------------------------------------------------------------------

:copynewest from passed foldername to dest foldername

set passed=%1
set newest=

for /f "tokens=*" %%a in ('dir /b /od "%passed%" 2^>nul') do set newest=%%a
copy "%passed%\%newest%" "%dest%"
DIR %dest%
PAUSE
goto :eof

[foxidrive]

On 26/04/2012 19:53, John Gray wrote:
> Someone posed the problem of wanting to copy the newest file from out of three directories into a fourth directory, and I thought of a number of ways of doing this. The one I settled on was to set up an intermediate directory, and copy the newest file from each of the three source directories to it, then copy the newest of the three files from the intermediate directory to the target directory. This avoids messing with date and time stamps across locales.
>

> I'd be interested if someone can think of a better/faster way of doing this..

This identifies the most recent file in a tree. It has granularity to the second and is not dependant on region/locale.

It was a question posed in a forum and two other solutions were given - one using WMIC to get better than second granularity and one using batch to get minute granularity. If you're interested I'll post them too.


@echo off
if "%~1"=="" (
echo Finds the most recent file in a folder and subdirectories
echo SYNTAX: "%~nx0" [path]
echo where path is the folder tree to check EG "d:\data files"
pause
goto :EOF
)
set "fileout=%temp%\tempfile.tmp"

(
echo Dim strPath
echo Set oFSO = CreateObject^("Scripting.FileSystemObject"^)
echo strPath = "%~1"
echo ' strPath = InputBox^("Enter Folder Path: "^)
echo Set fOut = oFSO.CreateTextFile^("%fileout%", True^)
echo DoStuff oFSO.GetFolder^(strPath^).Path
echo Sub DoStuff^(sDir^)
echo Set oDir = oFSO.GetFolder^(sDir^)
echo For Each i In oDir.Files
echo n = oFSO.GetFile^(sDir + "\" + i.Name^).DateLastModified
echo fOut.WriteLine CStr^(Year^(n^)^) + Right^(100+Month^(n^),2^) + Right^(100+Day^(n^),2^) + "-" + Right^(100+Hour^(n^),2^) + Right^(100+Minute^(n^),2^) + Right^(100+Second^(n^),2^) + " " + sDir + "\" + i.Name
echo Next
echo For Each i In oDir.SubFolders
echo DoStuff i.Path
echo Next
echo End Sub
)>"%temp%\vbsfiledate.vbs"

cscript /nologo "%temp%\vbsfiledate.vbs"
del "%temp%\vbsfiledate.vbs"
sort /r <"%fileout%" > "%fileout%2"

set /p "file=" < "%fileout%2"

for /f "tokens=1*" %%a in ("%file%") do set "file=%%b"

:done

del "%fileout%?"
echo The most recent file in the "%~1" tree is
echo "%file%"

goto :EOF




:: this is the raw VBS script, the basis of which was found via google and then modified.


Dim strPath
Set oFSO = CreateObject("Scripting.FileSystemObject")
strPath = "C:\Program Files"
' strPath = InputBox("Enter Folder Path: ")
Set fOut = oFSO.CreateTextFile("fileout.txt", True)
DoStuff oFSO.GetFolder(strPath).Path
Sub DoStuff(sDir)
Set oDir = oFSO.GetFolder(sDir)
For Each i In oDir.Files
n = oFSO.GetFile(sDir + "\" + i.Name).DateLastModified
fOut.WriteLine CStr(Year(n)) + Right(100+Month(n),2) + Right(100+Day(n),2) + "-" + Right(100+Hour(n),2) + Right(100+Minute(n),2) + Right(100+Second(n),2) + " " + sDir + "\" + i.Name
Next
For Each i In oDir.SubFolders
DoStuff i.Path
Next
End Sub





--
Mic

[Todd Vargo]

On 4/26/2012 5:53 AM, John Gray wrote:
> Someone posed the problem of wanting to copy the newest file from out of three directories into a fourth directory, and I thought of a number of ways of doing this. The one I settled on was to set up an intermediate directory, and copy the newest file from each of the three source directories to it, then copy the newest of the three files from the intermediate directory to the target directory. This avoids messing with date and time stamps across locales.
>
> I'd be interested if someone can think of a better/faster way of doing this.
>
> My code was:

<snipped>

The files in question can be any size. Lets assume they are large video
files. Your method will copy 3 very large files and then one of them a
second time. That assumes there is enough free space available for all 4
files. It would be practical and less time wasted to compare the dates
and then only copy the one that needs to be copied.

Since you asked for a better/faster way of doing this, either forget
trying to please the date-locale-batch-gods and just write it for your
own locale, or if locale independence is an absolute requirement within
your organization, just write a pure VBScript to compare file dates and
to copy the file.

--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)

[billious]

@echo off
:: select latest of 3 files for copying
setlocal
set f1=first.dat
set f2=second.dat
set f3=third.dat
for /f %%i in ( ' echo y^|xcopy /L /d %f1% %f2% ' ) do set r1=%%i
if %r1:~0,1%==1 (set f2=%f1%)
for /f %%i in ( ' echo y^|xcopy /L /d %f2% %f3% ' ) do set r1=%%i
if %r1:~0,1%==1 (set f3=%f2%)
echo copy %f3%

[billious]

On second thoughts, this is simpler:

@echo off
:: select latest of 3 files for copying
setlocal
set f1=first.dat
set f2=second.dat
set f3=third.dat

for /f %%i in ( ' xcopy /L /y /d %f1% %f2% ' ) do set r1=%%i
if %r1%==1 (set f2=%f1%)
for /f %%i in ( ' xcopy /L /y /d %f2% %f3% ' ) do set r1=%%i
if %r1%==1 (set f3=%f2%)
echo copy %f3%

[John Gray]

Thanks to everyone for their suggestions. I avoid VBScript out of sheer ignorance.

Billious: your method appears to have promise, but I'm afraid I cannot understand what your FOR statements do! These three folders may contain totally non-matching filenames, and the exercise is to find the newest file.

I've run the slightly-revised script on my sample folders (with added spaces for realism), but really am none the wiser...

@echo .off
:: select latest of 3 files for copying
setlocal
set f1=F:\Dan 09\Source A
set f2=F:\Dan 09\Source B
set f3=F:\Dan 09\Source C
for /f %%a in ( ' xcopy /L /y /d "%f1%" "%f2%" ' ) do set r1=%%a
if %r1%==1 (set f2=%f1%)
for /f %%a in ( ' xcopy /L /y /d "%f2%" "%f3%" ' ) do set r1=%%a

if %r1%==1 (set f3=%f2%)
echo copy %f3%

endlocal

[Todd Vargo]

On 4/26/2012 9:04 PM, billious wrote:

> On second thoughts, this is simpler:
>
> @echo off
> :: select latest of 3 files for copying
> setlocal
> set f1=first.dat
> set f2=second.dat
> set f3=third.dat
> for /f %%i in ( ' xcopy /L /y /d %f1% %f2% ' ) do set r1=%%i
> if %r1%==1 (set f2=%f1%)
> for /f %%i in ( ' xcopy /L /y /d %f2% %f3% ' ) do set r1=%%i
> if %r1%==1 (set f3=%f2%)
> echo copy %f3%

Well done.

[billious]

>
> Thanks to everyone for their suggestions. I avoid VBScript out of sheer
> ignorance.
>
> Billious: your method appears to have promise, but I'm afraid I cannot
> understand what your FOR statements do! These three folders may contain
> totally non-matching filenames, and the exercise is to find the newest
> file.
>
> I've run the slightly-revised script on my sample folders (with added
> spaces for realism), but really am none the wiser...
>
> @echo .off
> :: select latest of 3 files for copying
> setlocal
> set f1=F:\Dan 09\Source A
> set f2=F:\Dan 09\Source B
> set f3=F:\Dan 09\Source C
> for /f %%a in ( ' xcopy /L /y /d "%f1%" "%f2%" ' ) do set r1=%%a
> if %r1%==1 (set f2=%f1%)
> for /f %%a in ( ' xcopy /L /y /d "%f2%" "%f3%" ' ) do set r1=%%a
> if %r1%==1 (set f3=%f2%)
> echo copy %f3%
> endlocal
>

Well, you've taken the first step. Note that the spaces surrounding the
single-quotes are superfluous - used for emphasis and avoiding confusion
with the double-quotes you've correctly inserted.

The FOR /F command takes each line of the filename in parentheses in turn
and applies the DO clause to the line. If the "filename" is single-quoted,
then the output of the command is used as the input file.

There are a few documented and undocumented quirks and features. Empty lines
are skipped and so are lines commencing with a semicolon. You may add a
quoted directive string after the /F to control how the line's contents are
interpreted - for instance "tokens=1,3delims=abc" which means 'parse the
line of input using "a", "b" and "c" as delimiters to generate tokens. Apply
the first to the FOR loop metavariable (%%a in your code) and the third to
the next (implicit) metavariable, %%b. By default, delimiters are space,
comma, semicolon [and possibly tab] and tokens=1 so if these directives are
omitted, only the nominated metavariable is set to the value of the first
token. The line is interpreted as

delimiters token1 delimiters token2 delimiters token3 ...

(documentation, from the prompt

FOR /? |more

)

switching to the XCOPY command, the /L (I used upper-case for emphasis and
clarity) produces a Listing of the files that the XCOPY would attempt to
copy, but not actually copy them. The /d ensures that the "copy" takes place
only if destination datestamp is earlier than the source and the /y forces
the 'copy' to proceed without pausing for authority to "overwrite."

The output of the XCOPY command will therefore be

blah, blah, blah
n File(s) copied

where n would be the number of files that the XCOPY would ATTEMPT to copy.
Since the filenames fed to the XCOPY direct it to "copy" ONE file over
another, then n must be 0 or 1, controlled by whether or not the destination
filename is later than the source.

The FOR/F applies each line of XCOPY's output to the DO clause, so sets R1
to the first token from each line in turn. The value that will "stick" is
that on the last line, which will be the "0" or "1"

Hence all that remains is to establish the full-filenames of the three files
in question into F1..F3.

The skeleton for this is to use the same method on three directories: [air
code]

set d1=c:\wherever\
for /f "delims=" %%i in ( ' dir /b /a-d /od "%d1%*.*" ' ) do set f1=%d1%%%i

which performs a DIR listing on the target directory D1 in BASIC format
(name only) in date order, omitting directorynames. The ENTIRE line is
applied to the metavariable %%i controlled by the empty delimiter-set (the
close-double-quote appears immediately after the '=') hence there is only
one token. This permits %%i to contain spaces.

Again, each line of the DIR output is SET into F1 in turn, so the final
result in F1 is the concatenation of the directory name D1 and the final
value of %%i from the final line of the DIR output - the newest filename
since the DIR listing is in date order.

And if you don't need a coffee after all that - I do!

[John Gray]

I apologise: I understood much of what you were trying to do - but it doesn't work on my test directories. When I run your script I get something like 143 files copied (or rather, not copied!). Is some of it missing, because there is no DIR command anywhere in it, whereas there is in your fulsome explanation!

If I'm right, you are assuming that the contents of the three source directories are identical (bar a few timestamps) whereas my test directories have entirely different files. In fact each file exists in one directory only! The aim of the original questioner, as I understood it, was just to find the newest file in the three source directories, regardless of filename.

Perhaps you have assumed that your code was to be plugged somewhere into my original script? If so, I'm lost!

[Todd Vargo]

Correct, you were supposed to plug his code into your code. I would
suggest you include the /a-d switch to prevent any sub directory names
from being included as a file name. Try the following adaptation of
yours and billious' codes. All lines are indented 2 spaces. Any lines
beginning in the first column have wrapped from the preceding line. This
will display the file to be copied only. To activate the copy command,
remove the ECHO.

@echo .off
CLS
:: copy the newest file from three source folders
:: into a target folder

setlocal

:: folder names - replace as appropriate
set sourcea=F:\Dan09\SourceA
set sourceb=F:\Dan09\SourceB
set sourcec=F:\Dan09\SourceC

set target=F:\Dan09\Target

:: find the newest file in each of the source folders
for /f "tokens=*" %%a in ('dir/b/od/a-d "%sourcea%" 2^>nul') do set
f1=%%a
for /f "tokens=*" %%a in ('dir/b/od/a-d "%sourceb%" 2^>nul') do set
f2=%%a
for /f "tokens=*" %%a in ('dir/b/od/a-d "%sourcec%" 2^>nul') do set
f3=%%a

:: select latest of 3 files for copying

for /f %%i in ('xcopy /L /y /d "%f1"% "%f2%" ') do set r1=%%i
if %r1%==1 (set f2=%f1%)
for /f %%i in ('xcopy /L /y /d "%f2%" "%f3%" ') do set r1=%%i
if %r1%==1 (set f3=%f2%)
ECHO copy "%f3%" "%target%"

[billious]

We seem to have a distinct lack of clarity of the goal. An example of the
object would have been good.

It appeared you wanted to copy the latest one file of (three known files)

Then it appeared you wanted to copy the latest file of (all of the files
found in three directories) - which is the way that Todd appears to have
interpreted the problem

It would now seem, from your '143 files copied' response that your goal is
to copy the latest version of each file (by name) appearing in any of the
three directories.

The way I'd start is this:

@echo off
set d1=d:\dir one
set d2=d:\dir two
set d3=d:\dir three
del u:\f*
for /f "delims=" %%i in ( ' xcopy /L /d /y "%d1%\*.*" "%d2%" ' ) do
>>u:\f12.dat echo %%~nxi
for /f "delims=" %%i in ( ' xcopy /L /d /y "%d2%\*.*" "%d1%" ' ) do
>>u:\f21.dat echo %%~nxi

well, repeat the last two lines making the obvious changes to produce
u:\f13.dat f31.dat f23.dat and f32.dat .. I have a ramdisc named U:

The result in u:\Fpq.dat is then a list of filenames that are newer in
directory p than in directory q or don't exist in directory q.

Therefore if a line occurs in Fpq AND in Fpr then the version in p is the
latest. If in Fqp AND Fqr then q is the latest and if in Frp AND Frq the r
is the latest.

Hence a subroutine could be constructed, passing p, pq and pr to perform the
required tasks.

call :sub "%d1%" u:\f12.dat u:\f13.dat

The subroutine would simply take each line from one file and see whether it
could find an EXACT match in the other. If it can, then copy the filename on
the line to the target

for /f "delims=" %%i in (%2) do (
findstr /b /e /i /c:"%%i" <%3 >nul
if not errorlevel 1 copy "%~1\%%i" \target\ >nul 2>nul
)

The fly in the ointment is that the very last line of the data files would
be "143 File(s) copied" which just /may/ match its counterpart in the paired
file and hence a copy attempt would be executed on a file with that name. In
all probability, it would fail as it deserves to do. However, if you're
asking for trouble and have deliberately created a file of that name - well,
fix it yourself, clever clogs.

[Todd Vargo]

billious, I have a quick question about your newsreader settings.

Apparently, you use OE6, and since I was a long time OEx user also, I
know a bit of its quirks/behaviors. In the above quoted code from the
OP, his code lines that were remarked with "::" seems to have had the
"::" replaced with ">>". The only time that I recall OE ever doing this
was when I used OEquotefix, which is why I discontinued it's use in the
batch groups.

I also notice, this "::" replacement behavior is not consistent through
all of your responses in this thread, which leads me to believe that you
invoke OEquotefix manually to overcome the annoying quoted-printable
encoding (because OE does not render it correctly). I'm just curious if
you had ever noticed that your responses are misquoting the code from
the previous post?

[John Gray]

On Saturday, April 28, 2012 3:52:21 AM UTC+1, billious wrote:
> We seem to have a distinct lack of clarity of the goal. An example of the
> object would have been good.
>
> It appeared you wanted to copy the latest one file of (three known files)
>
> Then it appeared you wanted to copy the latest file of (all of the files
> found in three directories) - which is the way that Todd appears to have
> interpreted the problem
>
> It would now seem, from your '143 files copied' response that your goal is
> to copy the latest version of each file (by name) appearing in any of the
> three directories.

<snip>

> The fly in the ointment is that the very last line of the data files would
> be "143 File(s) copied" which just /may/ match its counterpart in the paired
> file and hence a copy attempt would be executed on a file with that name. In
> all probability, it would fail as it deserves to do. However, if you're
> asking for trouble and have deliberately created a file of that name - well,
> fix it yourself, clever clogs.

As far as I am aware the first line of the original post gave and adequate description of what was needed, except that it may not have made clear that SourceA, SourceB and SourceC were *folders* with files in them whose filenames did not necessarily match. They certainly weren't intended to be "almost" identical folders! Or filenames.

The "143 file(s) copied" was, as Todd appreciated, because I thought your revised code was a complete replacement for mine, and the message was the result of running your code as it stood. That's also why I couldn't understand how it could work.

Anyway, Todd has combined the two sections of code, giving me something to work with. I will also try to think of every eventuality next time I start a thread!

[billious]

On 29/04/12 03:24, Todd Vargo wrote:
> billious, I have a quick question about your newsreader settings.
>
> Apparently, you use OE6, and since I was a long time OEx user also, I
> know a bit of its quirks/behaviors. In the above quoted code from the
> OP, his code lines that were remarked with "::" seems to have had the
> "::" replaced with ">>". The only time that I recall OE ever doing this
> was when I used OEquotefix, which is why I discontinued it's use in the
> batch groups.
>
> I also notice, this "::" replacement behavior is not consistent through
> all of your responses in this thread, which leads me to believe that you
> invoke OEquotefix manually to overcome the annoying quoted-printable
> encoding (because OE does not render it correctly). I'm just curious if
> you had ever noticed that your responses are misquoting the code from
> the previous post?
>

Yes - correct analysis.

I avoided making the final switch to Thunderbird because I found that
sometimes Thunderbird failed to shut down properly. It would sit there
eating a CPU, which was not particularly noticeable with most activity
but crippled BOINC processing.

I scheduled a batch to pop up a warning if Thunderbird was running but
neither Firefox nor OE6 were running. Hasn't been activated in a while
though - so possibly the Tb bug is fixed and I can decommission the
batch and consign the OE and OEwithQF icons to the rarely-used bucket.

Two fewer icons on the desktop, less processing AND kosher posting...
Christmas!

[foxidrive]

On 29/04/2012 13:55, billious wrote:
>
> Two fewer icons on the desktop, less processing AND kosher posting...
> Christmas!

The kosher loving people don't celebrate Christmas though. Errorlevel 1 ;)




--
Mic

[billious]

Here's a tested version.

One potential bug with the XCOPY /L date-comparison method is that if
all of the directories contain identical copies of the same file, then
XCOPY's List won't contain ANY of them...

I tested this routine with safe tempfile names, silly (contain spaces)
directory names and very silly (contain ! and & and %) filenames. I'll
admit to not having tested it with all poison filename characters.

It seems to work for me. Structures deliberately selected to fit
standard line-wrap. If you use non-standard, you may have some work to do.

@echo off
:: copy latest version of each file by name
:: from 3 directories to a destination directory
:: Directories are presumed to already exist
::
:: lazy make-no-envvar changes
setlocal
::
:: establish directory names
set d1=c:\sourcedir\directory 1
set d2=c:\sourcedir\directory 2
set d3=c:\sourcedir\directory 3
set target=c:\destdir
:: three tempfile names
set t1=u:\temp1.txt
set t2=u:\temp2.txt
set t3=u:\temp3.txt
:: compare dir1 to dir2 and dir3; then 2 to 1 and 3,
:: finally 3 to 1 and 2
call :dcomp "%d1%" "%d2%" "%d3%"
call :dcomp "%d2%" "%d1%" "%d3%"
call :dcomp "%d3%" "%d2%" "%d1%"
call :clrtemp
:: finally, do the xcopy /d from a source to the target
:: to ensure that the target contains a file if all source
:: directories contain an identically-dated copy
XCOPY /L /d /y "%d1%\*.*" "%target%"
goto :eof

:dcomp
call :clrtemp
:: produce listing of files to be copied to tempfiles
:: Name preceded by colon which cannot appear in a name+ext

for /f "delims=" %%i in (

' xcopy /L /d /y "%~1\*.*" "%~2" '
) do >>%t1% echo :%%~nxi

for /f "delims=" %%i in (

' xcopy /L /d /y "%~1\*.*" "%~3" '
) do >>%t2% echo :%%~nxi
:: lop off the last line of both tempfiles
call :loplast %t1%
call :loplast %t2%
::
:: Look for all lines that now occur in BOTH files
::
for /f "delims=" %%i in (%t1%) do (
findstr /b /e /c:"%%i" %t2% >nul
if not errorlevel 1 ECHO COPY /y "%~1\%%i" "%target%"
)

goto :eof

:clrtemp
:: delete temporary files
for %%i in (%t1% %t2% %t3%) do del %%i 2>nul
goto :eof

:: lop off the last line of file %1
:loplast
:: force tempfile3 to contain just a new-line
>%t3% echo.
:: get last line number
for /f %%i in ( ' find /c /v "" ^<%1 ' ) do set count=%%i
for /f "tokens=1*delims=:" %%i in (
' find /n /v "" ^<%1 '
) do if not %%i==[%count%] >>%t3% echo %%j
:: and back to original file
copy /y %t3% %1 2>nul >nul
goto :eof


This is the display-only version, so the XCOPY in upper-case statement
may show duplicates of copies made by the COPY statements.

To activate,
1) remove the /L switch from the XCOPY statement (the ONE in upper-case)
and add a >nul to suppress messages.
AND
2) remove the ECHO keyword to activate the COPY statement, adding
redirection to nul to suppress messages as required.

[foxidrive]

What time accuracy does it go down to?


--
Mic

[billious]

On 30/04/12 00:20, foxidrive wrote:
[snip]

>
>
> What time accuracy does it go down to?
>
>

Whatever XCOPY /D sees as different.

So - did the programmer use only a part of the timestamp or all of it?

I wrote the following:

@echo off
setlocal
set c1=0
set c2=0
set loops=1000
:loop
echo.>file1
set /a loops-=1
echo.>file2

for /f %%i in (

' xcopy /l /d /y file2 file1 '
) do set /a c1+=%%i

for /f %%i in (

' xcopy /l /d /y file1 file2 '
) do set /a c2+=%%i
if %loops% gtr 0 goto loop
echo time detected different %c1% times
echo unexpectedly different %c2% times


The SET/A was intended to ensure that there was some delay between the
closing (=timestamping) of file1 and file2.

I was going to increase the delay by introducing an inner loop, but the
result was that the routine detected a time difference 44% of the time.
Fortunately, there were no instances where it was decided that the
second file was timestamped earlier than the first.

There was also a single instance of an error message "The requested
operation cannot be performed on a file with a user-mapped section
open." Since in standard style that gobbledegook doesn't specify which
filename or what operation, I'll conclude it's from XCOPY.

I believe that introducing a further time-delay is superfluous and the
experiment points to a reasonably fine granularity - certainly better
than the 2sec we've come to accept.

[Todd Vargo]

I have not noticed a failure to shutdown bug, but TB is updated
regularly so I may have began using it after it was fixed. I use the
portable version so its easy to take it with me from machine to machine,
unlike OE which is tied to the registry. If MS would have fixed the
quoted-printable bug, I would have never left it. Prior to the switch to
TB, I used a vbscript to correctly translate q-p posts but it was more
trouble than worth the effort due to the increased number of
googlegroups posts.

[foxidrive]

On 30/04/2012 03:21, billious wrote:
> On 30/04/12 00:20, foxidrive wrote:
> [snip]
>
>>
>>
>> What time accuracy does it go down to?
>>
>>
>
> Whatever XCOPY /D sees as different.
>
> So - did the programmer use only a part of the timestamp or all of it?
>

[snip]

I used this:

@echo off
echo abc>1
echo abc>2

and wmic gave me this as the timestamps:

LastModified Name
20120430035504.261125+600 d:\abc\1
20120430035504.276750+600 d:\abc\2


Then xcopy produced this:

d:\ABC>xcopy /l /d /y 1 2
0 File(s)

d:\ABC>xcopy /l /d /y 2 1
D:2
1 File(s)

so it looks like xcopy uses the full timestamp and accuracy is down to milliseconds.



--
Mic

[Todd Vargo]

Ah, but some do. Errorlevel 2 :O

[foxidrive]

On 30/04/2012 06:24, Todd Vargo wrote:
> On 4/29/2012 6:48 AM, foxidrive wrote:
>> On 29/04/2012 13:55, billious wrote:
>>>
>>> Two fewer icons on the desktop, less processing AND kosher posting...
>>> Christmas!
>>
>> The kosher loving people don't celebrate Christmas though. Errorlevel 1 ;)
>
> Ah, but some do. Errorlevel 2 :O

Not those that keep kosher, surely. Errorlevel 0




--
Mic

[billious]

Heh. Found a bug.

The capitalised XCOPY needs to repeated with either one of %d2% or %d3%
to cater for the situation where d2 and d3 contain identical files that
are missing from d1.

Which actually brigs us back to the simplest solution:

XCOPY /d /y "%d1%\*.*" "%target%"
XCOPY /d /y "%d2%\*.*" "%target%"
XCOPY /d /y "%d3%\*.*" "%target%"

I wonder whether all the gymnastics are worth it - after all, the only
apparent fault with this solution would be where the later-processed
directories contain very large later files. Very small later files would
likely be quicker to copy and recopy than would all the twisting and
turning required to filter the latest version.

[Todd Vargo]

This is the 21st century. <shrug>