[<<]Message[>>] [<<]Author[>>] [<<]Subject [<<]Thread
Number : 504 Date : 2001-08-01 Author : Kan Yabumoto Subject : Re: creating groups of files Size(KB) : 5
My thought on the idea for groups of directories......... The suggestion that tj described (to create a group of directories by the total byte count) is interesting and probably useful in other purposes besides the first step in preparation of burning CDRs. ----------------------------------------------------------------- If you think of the process to automate this, I wish many of the CDR burning software (such as EZ-CD creator) has provisions for command-line processing mode (for inclusion in a batch file). If that's the case, we can easily make the whole operation that tj was talking about into a more automated script (albeit, you still need to become the disc-swapping robot). It is a shame that the user-friendliness that are offered by GUI tools comes with a mostly-unnoticed penalty of not being able to script. ----------------------------------------------------------------- Earlier, we also saw a question/suggestion which asked if XXCOPY could count the number of files before it stops. These can be viewed from the same angle. To use a parameter (either the byte-count or file-count) to initiate another action (could be to terminate the operation, to pause with a user-prompt --- for a media swap in case of volume spanning, or to create a destination subdirectory in a iterative-way) can be grouped into a powerful XXCOPY command. The previous implementation of spamming was always tied to the disk-full condition. But, you could benefit if you leave certain amount of free space on the media before it move to another disc. Of course, it would be even better if XXCOPY computes the required space (using the cluster size of the destination drive) rather than the total byte count. The only remaining issue with this is the command syntax to describe all this... For example, /foreach_bytetotal:100M /next_end /foreach_bytetotal:650M /next_pause /foreach_bytetotal:650M /next_mkdir /foreach_filetotal:500 /next_mkdir Here, of course, we will probably make the command switch to be shorter (and more cryptic :-( to confuse people). But, the point is the /foreach_xxxx series of switches limits the XXCOPY operation one way or another and add certain action (/next_xxxx) to perform which may be combination of them: /next_pause // user prompt Now, the /next_mkdir give an numeric subdirectories (one-level immediately below the destination directory) like \dst\mydir\0000\ \dst\mydir\0001\ \dst\mydir\0002\ ... -------------------------------------------------------------- Alternatively we could introduce a new macro feature to count the iteration... /next_md:mydir/$cnt$ // pre-defined count variable 0, 1, ... /next_md:mydir/$cnt2$ // count variable 00, 01, 02, 03,... /next_md:mydir/$cnt4$ // count variable 0000, 0001, 0002,... This is probably overkill. The fixed format(four-digit numeric series shown above) will probably suffice it. --------------------------------------------------------------- Well, I'm probably carried away too far... The simple idea of limiting the xxcopy multiple-file operation into smaller chunks of action and do a few variety (or combination of them) things before continuing is a neat thing. So far, I came up with three variations in the inserted action between the groups of operation: /next_end /next_pause /next_mkdir And, I gave just two ways to set the limit on operation /foreach_bytetotal: /foreach_filetotal: but we could also add /foreach_diskfull and if we combine this with /next_pause, /foreaoch_diskfull /next_pause that is what is the current behavior of the /SP switch. Of course, this is a new development I just conjured up as the extension of the idea of grouping the directories... The /SP has been in my mind for quite some time now to make the use of incremental backup with a backup set of CD-R discs. We need many more nights' sleep (or nightmare) to hit the right idea... Well, my mind has gone wild and I wonder how many of you could follow my train of thoughts here. Ciao Kan Yabumoto ================================================================ At 2001-07-31 17:07, Joseph Maddison wrote: >This sounds suspiciously like spanning. The latest version of WinZip, >8.1 Beta, will support splitting into separate files without going >to removable media in the process. You could like up your files, >specifying a 650 MB chunk, and then move those chunks onto CD. > >If you'd rather have files visible directly from the CD (though you'd >have an issue of which file is on what CD, though there are programs >to track this...) I would suggest making a 650 MB partition on your >hard drive. Use XXCOPY with the operation that marks files backed up >with the archive bit set, and then copy files until the partition fills. >Then make a CD of the 650 MB partition, clean it out, and then repeat >the copy (or move) operation. As long as it is something that progresses, >like a move or setting the archive bits (Kan can you elaborate on >this?), you won't be copying the same first 650 MB of files over. > >If you have something like the Packet writer that is a part of Adaptec's >Easy CD Creator, you can skip the partition and simply copy to the CD >until it is full, then start over with a new one. > >Hope this helps,
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.