[<<]Message[>>]    [<<]Author[>>]    [<<]Subject        [<<]Thread[>>]

Number   :  7760
Date     :  2004-04-25
Author   :  labcore
Subject  :  Re: How to make XXCopy delete extra files in destiny before copying
Size(KB) :  9


Hi Kan! Thank you very much for your detailed answer (I really 
appreciate how detailed your answers and explanations use to be - in 
fact, XXCopy users have two of their dreams turned into reality: 
access to a very powerful, flexible file copy utility and a decent 
customer support, as every one should be). Oh, yes: thanks for 
revising and "cleaning up" my set of switches, too (it was good to 
eliminate all the redundancy, although I still prefer to include some 
of the default ones, just in case some default behavior of XXCopy 
changes...). Anyway, keep up the good work!

Now back to my question. I forgot to say that I've already used the 
following command line in my batch files to delete extra files in 
destiny before synchronization:

"xxcopy b:\destiny\ a:\source\ /RS /BB /H /R /E /WV0 /YY /Q1"

Then, after that, the next task performed was the copy process 
itself, currently expressed by the following command line:

"xxcopy a:\source\ 
b:\destiny\ /BN /CK /CR3 /E /FW /H /I /K /NW /NX /oE3 /PB:1M /PC0 /PN 
/Q2 /R /TC /TTA0 /V2 /WV0 /YY /ZY /oAbackup_xxcopy_log.txt"

As expected, the two command lines above always worked fine. But, as 
an effort towards the quest for an even smaller and simpler batch 
file, I'd like to know if XXCopy can do it all (both tasks) in just a 
single step (that is, by providing me the possibility to substitute 
those two distint command lines for just only one, while getting the 
exactly same results of both of them). Because the /RX switch doesn't 
allow the copy process to start immediately after the extra files are 
deleted and as the couple /RS/BB requires that source and destiny are 
swapped to reach the goal I'm looking for, I have no option but to 
write a second command line just for the copy (or synchonization) 
job. So, the ideal solution (as far as I can wonder) would be 
getting /ZY to delete ALL extra files in destiny (in just a single, 
sequencial task) just *before* the file copy from source to destiny 
started (and not *during* the file copy process)... E.g.: if there 
were 50 extra files in destiny to be erased (even if they were in 
different folders throughout the destiny's logical structure), all 
those 50 files should be deleted in a row; only after they're were 
gone, then the file copy process would start. Could a "fix" to 
the /RX switch be done so that it could accomplish this behavior or 
is there some existing workaround for this issue that I'm not aware 
of?

PS 1: The /BZL trick is a very good "enhancement" for /BB, in the 
context of my needs. If I have to keep on using two separate command 
lines, I'll consider it.

PS 2: I have other questions which I couldn't find in this group, but 
I'll post them in a new message, so they can be easily found and 
followed by other members, OK?

Regards,

Rodrigo Faustini
www.faustiniconsulting.com
www.rodrigofaustini.com

April/25/2004


--- In xxcopy@yahoogroups.com, Kan Yabumoto  wrote:
> 
> labcore wrote:
> >
> > Hi!
> >
> > In a one-way synchronization job, if we want that XXCopy
> > deletes in destiny extra files and/or folders that don't
> > exist in source anymore, we must use the "Z" or "/ZY" switch.
> > But how to make it delete ALL those extra files in destiny
> > BEFORE it starts copying files from source to destiny,
> > with just a single command line?
> 
> The short answer is to use the /RX operation which fits
> the bill exactly.
> 
> Here's some extra study material for advanced users.
> 
> Those who are lurking here may wonder why anyone want to
> run the /ZY operation without copy. The answer is, of
> course, to avoid possible out-of-space condition.
> That is, when you have sufficient amount of free space
> in the destination volume, there is no reason to run
> the file-removal operation before the incremental backup
> operation. But, when the destination volume is very close
> to the full usage, the deletion of all extra files before
> starting the copy operation makes it close to optimum.
> 
> To push this concept to its extreme, one could not only
> delete extra files, but also all the files that are to be
> replaced by a smaller one (see below for an actual example)
> in the first step before the incremental backup (sync)
> operation.
> 
> It is essentially a delete (remove) operation.
> 
> XXCOPY provides four types of remove operations.
> 
> /RS // removes from source directory
> /RC // removes from source after a successful copy
> /RD // removes from destination (what would be overwritten)
> /RX // removes from destination anything extra
> 
> Now, /RC is just a variation of a copy (like a move) and
> we are not interested in this. /RD removes something
> that are common in both source and dst, and this is not it.
> /RS is the most versatile one (with /U, /BB, etc. to make
> many variations). /RX is very much like /Z or /ZY except
> that this one does not perform any copy operation.
> 
> So, the answer is /RX which is /Z without file copy.
> 
> xxcopy \dir1\ \dir2\ /Z // copy and delete extra from \dir2\
> xxcopy \dir1\ \dir2\ /RX // delete extra from \dir2\
> 
> The answer is /RX and this is probably what you want.
> But, bear with me for a little extra lesson...
> 
> Although XXCOPY seems to provide many variations in deletion,
> if you allow the source and destination directories swapped,
> both the /RD and /RX operations can be substituted with
> the /RS operation (which is the most universal type).
> 
> E.g., the following pairs are equivalent
> 
> xxcopy \dir1\ \dir2\ /RD // delete common files in \dir2\
> xxcopy \dir2\ \dir1\ /RS/U // equivalent to /RD in reverse
> 
> xxcopy \dir1\ \dir2\ /RX // delete extra files in \dir2\
> xxcopy \dir2\ \dir1\ /RS/BB // equivalent to /RX in reverse
> 
> Now, the last pair of examples is similar to the first answer.
> But, generally speaking, the /RS operation is the most
> versatile of all. Here's the reason:
> 
> 1. the /Z (or /ZY) operation deletes the extra files and
> directories unconditionally. For example, even if the
> file has the Read-Only attributes, it will be deleted.
> 
> 2. the rich set of file-selection functions in XXCOPY
> operate on the source files. Therefore, by placing the
> objects to be deleted at the center stage (the source
> specifier), you can take advantage of many more way
> to fine-tune the file-selection --- by date, age,
> size, attributes, exclusion, etc.
> 
> E.g.,
> 
> xxcopy \dir2\ \dir1\ /RS/BB/DB#30 // old files only
> xxcopy \dir2\ \dir1\ /RS/BB/SZ:1M- // large files only
> 
> Note: unlike /RX, the /RS/BB operation respects the
> Read-Only attributes (needs /R to delete) and hidden/system
> attributes (needs /H to delete hidden/system files).
> Again, this should be viewed as more flexibility.
> 
> 3. When the destination volume's free space is extremely
> tight, the following operation will avert some possible
> out-of-space conditions which may otherwise occur.
> (This is a concrete example that my first paragraph
> promised.)
> 
> xxcopy \dir2\ \dir1\ /RS/BZL/S/H/R/YY
> 
> (But, frankly, this is a last resort trick. I would
> rather upgrade the hard disk with more capacity.)
> 
> 
> 
> 
> 
> > The switches I use are:
> >
> > "/BN /CK /C0 /CR3 /E /FW /H /I /K /NW /NX /oE3 /PB1 /PC0
> > /PN /Po0 /Q1 /Q2 /R /TCA /TCC /TCW /TTA0 /V2 /WV0 /Y /YY
> > /ZY /oA%backup_temp%\backup_xxcopy_log.txt
> 
> I assume you derived this list from XXCOPY's log file
> which is great in debugging but it is almost too
> unpractical to keep a batch file more readable. In the
> case of the log file, XXCOPY has no choice but to
> exhaustively list all relevant switches because of the
> purpose of the list. On the other hand, some people
> prefer to spell out everything in the expense of
> excessive verboseness. One possible benefit of this
> practice is that in the rare event of a change in
> XXCOPY's default behavior, you need not change the batch
> file.
> 
> 
> /Po0, /Y and /YY are superfluous (/YY suffices it)
> /TCA/TCC/TCW can be replaced with /TC
> /Q1/Q2 is equivalent to /Q2 (Last one prevails)
> 
> /PB1 is an extreme setting which simply slows down
> with no practical benefit. The parameter to the /PB
> switch sets the lower limit to the progress bar on
> each file. A very small file does not warrant a
> progress bar which simply slows down (or you would
> not be able to see anything anyway). If you think
> the default setting of /PB:1M is too large, you may
> find something more reasonable one like /PB:50K.
> In most systems, there are a large number of very
> small files (e.g., cookies) that does not deserve
> a progress bar display. Of course, I suppose that
> the job is run at a wee-hour and the speed is probably
> of no concern here... (If you want to slow down the
> operation on purpose, we can always use the /NI
> switch).
> 
> In most cases, /C0 should be avoided. With /C0, the first
> instance of an error will terminate the whole job. The
> reason for its existence is primarily to allow you to
> emulate Microsoft's XCOPY without /C. But, when you have
> a large job, I just don't see any advantage of /C0.
> The /oE3 switch will show you the reason for each failure.
> 
> ----------------------------------------------------
> Some time ago, we changed the default setting of
> /C0 to /C. This was indeed a very special case
> where the change deliberately broke the XCOPY-
> compatibility with respect to this feature. As
> I said earlier, the /C0 setting is almost
> unjustifiable for a default operation. We were
> pretty much forced to do this to reduce the tech
> support load.
> ----------------------------------------------------
> 
> Kan Yabumoto



This message if part of XXCOPY's message Archive.
The archive contains all the messages posted at Yahoo!Groups: XXCOPY.