![]()
[<<]Message[>>] [<<]Author[>>] [<<]Subject [<<]Thread
Number : 3368 Date : 2002-12-24 Author : Kan Yabumoto Subject : Re: stop span /sp from eraseing the destination Size(KB) : 5
Here's a reversal of our position on the /SP switch. That is, we are going to add a variation in /SP (span) so that the user will now have a choice of blanking the media first or appending new files to existing ones without deletion. The added feature will debut in the next beta test version. ------------------------------------------------------ I gave a little more thought on the /SP behavior and re-examined what I was thinking about the necessity to clear the media before doing anything else. And, I have changed my mind that it is quite useful and relatively easy to keep track of the directories and files in the media with spanning operations. So, in the future release, we will have the following variations: /SP // the same as /SPB (old behavior) /SPA // append to existing contents on the volume /SPB // blank the media before start recording With the new switch, /SPA, you can record files and directories on the media without any deletion of existing files and directories. In this mode, it is entirely up to the user how to manage the directories and files. My suggestion for a repeated backup job is to create a unique destination directory name. xxcopy c:\ x:\dec23\ /DA#7/S/H/Y/SPA you may use a macro reference to name the destination so that the same batch file may be used for different days. xxcopy "c:\My Documents\" x:\bu_mydoc\/$yy-mm-dd$\ /DA#1/S/SPA This one saves files that were created since yesterday into the destination directory which is named after today's date (e.g., X:\bu_mydoc\02-22-23\ ) and if the destination media gets full in the middle of the job, it will prompt for a new media. In this case, the second media should probably be blanked before inserted for XXCOPY's continuation after the pause. This is because if you repeated the same operation more than once on the same day, you will have the destination directory (and some contents) on the media even before you start this command. When the target directory is spanning over two discs, then, you may not always overwrite a file on the same disc, resulting in two discs having the same-named files and it may be difficult to reconcile the situation. Say, you have a set of files in C:\mydir\ and you use the /SPA command the first time and the directory will be split into two discs. xxcopy c:\mydir\ x:\Tue\ /SPA /Y C:\mydir\ Disc #1 Disc#2 ------------------------------------------------------ \mydir\file1.txt \Tue\file1.txt \mydir\file2.txt \Tue\file2.txt \mydir\file3.txt \Tue\file3.txt \mydir\file4.txt \Tue\file4.txt Now, you repeat the same job late on the same day, xxcopy c:\mydir\ x:\Tue\ /SPA /Y Suppose all of the four files grew in size during the day, and when you run the same, command, the first file (file1.txt) made the first disc to be full. XXCOPY will then prompts you to insert the next disc before file2.txt is to be written. The end result will be as follows: C:\mydir\ Disc #1 Disc#2 ------------------------------------------------------ \mydir\file1.txt \Tue\file1.txt \mydir\file2.txt \Tue\file2.txt \Tue\file2.txt \mydir\file3.txt \Tue\file3.txt \mydir\file4.txt \Tue\file4.txt In this scenario, file2.txt will be present in the both discs. Perhaps, there are many more scenarios that may not produce the most desirable layout of the backup directories on the media. This kind of situation was what I was afraid to happen. As long as the user is aware of the fact that some end result may become confusing using the /SPA switch. In the above example, one way to keep strange things like that from happening is to make sure the name of the destination directory is always unique. Kan Yabumoto ============================================================= At 2002-12-20 16:25, you wrote: >Jimmy: > >There is none. That is, currently, the /SP operation >is not designed for an incremental backup. > >While there is no harm that would be caused by eliminating >the complete-erasure of the previously written files/directories >on the media, I just can't see how an average (or even >advanced) user can keep track of the set of a backup >(or whatever intended operation might be) discs when >an /SP operation is used in any backup operation. > >If we were to implement the /SP-without-erasure operation >as implicitly asked by Jimmy, it would then disable >practically all switches which checks or acts upon >the existing items on the destination (except, perhaps, >the /R /oO and /Y --- to control a file overwrite) >(actually, I believe such measures are already taken). >But, if we assume that the user knows what he is doing, and >finds such a version of /SP operation desirable, there is >little reason why we cannot provide such a feature. > >Usually, we do not inhibit the user from choosing a >combination of switches that makes little sense as long >as such an action does not contradict within the XXCOPY >operations. In the /SP case, we were so sure that it >made little sense (and we predict a lot of chaos would >result --- and the tech support burden by that) , >we chose the current design (by always performing >the complete erasure of existing objects on the media). > >If anyone other than Jimmy says it may be (even remotely) >interesting, we will add a special switch to disable >the erase-before-write operation. > >If Jimmy can elaborate on why he wants it that way, >we could explore more possibilities. > > >Any comment, anyone? > >Kan Yabumoto
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.