[<<]Message[>>] [<<]Author [<<]Subject[>>] [<<]Thread[>>]
Number : 3340 Date : 2002-12-17 Author : taitkj Subject : Re: The /RX operation --- a major bug!!! Size(KB) : 7
Kan, I agree with Ed. It is a good feature for those that know the usefulness of it. For my purpose, I could switch the destination and source in my script and just ues the /RS switch to remove extra files in my backup (even though it will treat my backup as the source) directory. The /CLONE feature works well enough for me since this is a fresh backup. My old backup is the one I was going to try and cleanup, but again, I can use the /RS switch for that purpose. Thanks for the extremely well written explanation of what your thoughts are on this topic. Tait BTW, if no one has told you today, great product. --- In xxcopy@yahoogroups.com, Kan Yabumoto wrote: > Tait's message brought an important issue here. > > As to the nature of your problem with the /RX operation, > it turned out to be a fundamental problem in XXCOPY. > That is, apparently the /RX switch had this bug of not > traversing all of the directory paths as it should. > > What surprises me is the /RX function which was introduced > back in June of 2000 with v.2.40.0 along with the other > remove switches (/RS, /RC, and /RD) became broken in the > major release of v.2.60.0 in July of 2001 (I just tested > all the previous versions to pinpoint which code change > started to have a bug like this). > > Be assured that we are currently working on this bug. > But, we have a mixed emotion on this feature which is > controversial in the designer's self examination. > > If you are interested in reading how XXCOPY has been > evolving, read on. There are a lot of things that > goes into our mind. > > --------------------------------------------------------- > A little bit of history... > > Actually, V.2.60.0 was quite a significant release in > XXCOPY's history; it was the first version which > differentiated the XXCOPY-Pro version from the freeware. > And, that was the time we started to be a lot more > serious about XXCOPY as a commercial product (before that > time, it was a side show in our software publishing > business known as DCOPY/DCOPY32 and was bundled free > with DATMAN. We cleaned up a lot in the new release > for v.2.60.0 after about 5 months of internal work. > As a matter of fact, this discussion group was formed > in May of 2001. So, at that time, we were in the middle > of beta testing in this group with early members. > ---------------------------------------------------------- > > Anyway, soon after the /RX switch was introduced, we > started to regret the addition of the /RX switch. > If you take a look at the four removal-related switches, > you get some idea. > > /RS // remove files from source > /RC // remove files from source after a successful copy > /RD // remove files from dst which would be overwritten > /RX // remove files from dst which are extra (like /Z) > > From the beginning, the /RX switch was an odd ball. The > other three really make sense in their respective role > in XXCOPY's file management operations. In principle, > when we add a new feature, we always try to generalize > a particular operation first. We explore all sorts of > possibility in how we can make it as general as possible. > In the case of file-deletion operation, we wanted cover > as much area as possible because a deletion should be > one of the major XXCOPY operations. > > The delete group of operation should be as versatile as > the more orthodox file copy operations. So, we take these > command quite seriously. As a matter of fact, while > there are numerous file-copy utilities on the market, > I say XXCOPY's extensive support in file/directory deletion > sets XXCOPY apart from other tools. > > One can argue that a tool like this should be specialized > with one feature. I tend to agree on that viewpoint in > principle. But, the idea of exploiting the very rich set > of file/directory selection/exclusion features for file copy > into the file deletion operation is quite irresistible. > Once one sees how the /RS, /RC, etc. works with the same > set of the XXCOPY basic feature, he will immediately > agree to the positive side of this integration. > > Since we already had the /Z (and /ZY which is part of > /CLONE) as a form of a delete operation, it was semi > natural to throw in the /RX operation which is equivalent > of the regular file copy operation with /Z except that > no file-copy operation will take place. And, that is > what the /RX operation is and should be. But, does it > fit into the rest of the XXCOPY operations naturally? > We have been agonizing on this issue ever since. The > reason for our lack of enthusiasm about the /RX switch > is that the /RS operation in combination with /BB switch > will perform the same operation as the /RX switch by > simply swapping the source specifier and the destination > specifier. > > More importantly, the /RS/BB combination offers a > substantially more versatility. If you closely examine > how XXCOPY approaches a given file-management operation, > you find that the "target" directory and its files will > be put into the "center stage" by specifying in the > source specifier. *ALL* of the file-qualifier switches > such as /DA, /DB, /SZ:, /ATxx, etc. are effective on > only the source specifier, not the destination specifier. > This alone makes the comparison between /RX and /RS/BB > tip its scale in favor of the /RS/BB combination. > > The only justification for the existence of the /RX > switch seems to be that it can be used to remove things > from the directory which is normally regarded as the > "destination" in a typical backup operation. But, > swapping the source and the destination specifier > for a few specialized operations like /RX (and other > non-copy operations) should not conceptually a very > difficult thing to understand. Moreover, a user may > be puzzled by adding a few /H, /R, /SZ: and other > switches which have no effect in de-selecting certain > class of files when /RX is used. This behavior is > indeed a pitfall to practically *ALL* users who might > try the /RX operation. Currently, the /RX operation > just like the /Z operation acts on the extra files in > the destination whose counterpart is not present in > the source directory without any other consideration. > That is, the absence of the counterpart in the > corresponding source directory is the sole mechanism > for deleting a file with the /RX (and /Z) operation. > > Although it may sound "helpful" in treating the /RX > case as an exception to incorporate the effects of > the other switches such as /Dxx, /H, /R, and /SZ: to > modify the file selection mechanism of the /RX operation, > making this kind of exceptions will leads to a total > chaos (from programming point of view, to implement > it that way would not be very hard). In a complex > tool such as XXCOPY, it is extremely important for > us to keep the set of rules to be as consistent and > predictable as possible. Exceptions to the rules > makes it very difficult to learn even though with > a case like this, it sounds counter-intuitive. > > This is why we regret the presence of the /RX switch > in the first place. The fact no one reported the > /RX bug for so long tell us one thing. That is, if > we quietly remove the /RX feature from the next release, > very few people would notice it. As a matter of fact, > we are seriously considering it as possibly the best > solution in the long run. > > Anybody, any comment on this issue? > > Kan Yabumoto > ====================================================== > At 2002-12-15 21:11, taitkj wrote: > >Chaz, > > > >I tried the /S again. Still to no avail. It will remove nonexistant > >files in the destination that no longer appear in the source, but it > >still will not go through the subdirectories. This is the result: > > > > > >F:\Documents and > >Settings\Tait\Desktop>xxcopy.exe "F:\Palm\KjellbT\" "C:\Palm\Kj > >ellbT\" /RX/S/YY/OA"RemoveLog.txt" > >
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.