[<<]Message[>>] [<<]Author[>>] Subject[>>] [<<]Thread[>>]
Number : 3337 Date : 2002-12-17 Author : Kan Yabumoto Subject : The /RX operation --- a major bug!!! Size(KB) : 6
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.