[<<]Message[>>] [<<]Author[>>] [<<]Subject [<<]Thread
Number : 3440 Date : 2003-01-04 Author : Kan Yabumoto Subject : Re: Any way to copy a fixed list of files to another Size(KB) : 6
I thought this question of expanding the /IN switch into a glorified version was already settled. But, when I hear this from Joseph (who is a long time veteran of this group), I have to give a complete explanation. Still, we haven't really added the /EIN switch that is for an "External IN-parameter file" which is very much in parallel to the /EX switch that is for an "External X-parameter file". The reason is that the /IN operation is limited to the lastname-only, unlike its counterpart in the /X and /EX cases. The trouble we will have from accepting fully-qualified full pathnames in the extended /IN switch is that we will lose track of where the "reference point". That is, XXCOPY's operation has been rigidly tied to the basic concept of having the "source base directory" and the destination base directory which corresponds to the source. All subdirectories under the "source base directory" will be replicated in the "destination base directory". An /X parameter which is given as a relative path will be treated as implicitly relative to the source base directory. The wild-wildsource feature (allowing wildcards anywhere for any number of times in the source) makes it important that the whole source directory will be traversed just once, for exactly one time. So far, XXCOPY's implementation of a job is to identify the source base directory (the longest path without any wildcard) and the destination base directory first. And then to go through the traversing of the tree underneath. While it traverses the tree, it will handle /Z (deletion of extra objects in the destination), and the unconditional creation of destination if needed (with /E), prompting at each entry point of a directory (for /PD), keeping track of the partial-response (for /PD's Y/N/A/R/S). And each and every exclusion items that have been complied from the command line (including the external files such as /CF and /EX). All this scheme works quite harmoniously since XXCOPY knows where is the base directory and it only needs to go through the whole range of the tree just once. Now, if you allow a list of arbitrary path for an item (or items if wildcard is allowed in the list), you will have as many number of "the source base directories" as the number of items you include in the list. It seems that the only way to make XXCOPY accept such a scheme is to disable a very significant number of existing switches in order to allow the multiple-source operation. For example, all of the /Bxxx operations (backup based on what's on the destination) as well as /X, /EX. Since each entry in "the source list" must be treated as a fresh start of XXCOPY operation (no directory traversing --- a huge departure from how thing were done), even the way the /IN switch was used will have to be disabled --- /IN*.MP3 no longer makes sense because we are dealing with one source item as an isolated object. One possible problem is can we contain such an operation from wanting more than one destination directory? If you allow a list of source items in an arbitrary fashion, it is natural to assume the user wants the destination to be also more than one. Then, we are talking about a situation c:\src1\file1.txt ---> c:\dst1\ c:\src2\file2.txt ---> c:\dst2\ c:\src3\file3.txt ---> c:\dst3\ Now, if you take a look at this kind of individualized control by specifying a filename and the destination directory (possibly allowing the much dreaded rename-while-copy mode) on each copy item, it looks very much like a batch file with individual invocation of the COPY command. By having XXCOPY controlling the job, you can certainly retain some features such as limiting the size to be within certain range, or skip the operation if other conditions are examined (such as attributes, size, date, etc.). But, a batch file with XXCOPY currently supports all of this. So, this makes a complete circle. If you have two or more unrelated items (files or directories) and you have necessary tools to automate the creation of such a list file (usually a pretty large), why does any one want to squeeze everything into one invocation of the XXCOPY program. If the operation forces XXCOPY to depart from the very efficient and harmonious model of one source base directory ---> one destination base directory by abandoning much of what XXCOPY has to offer? The acceptance of multiple-source items would make the documentation very complex. Practically *ALL* switches have to be explained in the two modes of operations --- one for the traditional one-src => one-dst model and the other for the new chaotic multiple-src => mult-dst model. The fact is the current set of XXCOPY command used in a batch file has the ultimate flexibility. It does not have any arbitrary limit in the number of lines in the batch file --- a batch file with several thousand lines are not very common. But, what is wrong with that? One may argue the execution efficiency. The truth is that repeated executions of XXCOPY.EXE does not force the disk drive to access the XXCOPY.EXE file the same number of times as it is executed on any of the Win32 environment today. In the end, converting a batch file into another form of script makes little sense. It's mostly shifting where the processing will be taking place. That is, if we were to implement the glorified /IN switch the way most people want it is to have XXCOPY to behave a "batch" processor, internally doing as simple-minded COPY operation with little use of other file-qualifying switches (because they have to be disabled). The only major advantage is to avoid loading the XXCOPY.EXE program repeatedly --- but, today's PC/Windows already takes care of repeated EXE-file loading using many levels of caching. So, no matter how many times we visit this issue, our design seems to make it mostly equivalent of COPY command inside XXCOPY. Kan Yabumoto ========================================================= At 2003-01-03 09:12, you wrote: >I think he's looking for a /IN equivalent to /EX. The answer's still no, but >this doesn't seem too unreasonable for a feature request. (After everyone >else's pet projects, of course). > >Otherwise, if he could mark the files he always wanted to copy with 'attrib >+a /s file' or, more likely, if he excluded the ones he didn't want with >attrib -A, XXCOPY with the /AT switch could pick up just the files with the >archive attribute set that he wanted to copy. Any new files placed in the >tree >would default to being copied. A little convoluted, but it could work. > >Joseph Maddison >Minneapolis, MN > > > To answer your question, no, there is no mechanism for XXCOPY > > to take a list of input files.
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.