[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread[>>]
Number : 3480 Date : 2003-01-08 Author : Kan Yabumoto Subject : Re: EXTREME alarm Size(KB) : 13
Yuku: First of all, let me say that it is our worst fear come true to hear that a user loses a lot of files using XXCOPY. We put a very high priority in the design to prevent any accidental loss of files. If the users are annoyed by the exceedingly annoying warning prompts everywhere, I have no apology for that. At least, until the user learns the trick of adding the proper switch to suppress the warning (hopefully after reading and understanding what the warning is trying to say), the user will be protected from an instantaneous loss of files. That is why we discourage people from using /YY. Before giving you a concrete answer, I was trying to figure out what could have gone wrong with your command. I have gone through a lot of scenarios. (This delay of my response was a result of trying to give you something informative and trying to avoid speculation as much as possible). One thing I did not hear (which is always very vital in troubleshooting) is which Windows version that you are running. It is nearly as important as the XXCOPY version. That is, a very substantial portion of our problems are results of very subtle differences in behavior between the Windows OS. The big divide is between the 9X/ME family and the NT/2K/XP family. Even though Microsoft calls them "Win32", the two environments are quite different in small but significant ways. Earlier today, Melissa reported some funny error condition with the missing server (I will address it in another message). That is also related to Windows version (in Melissa's case, I believe it is Win9X's bug). So, please tell us the Windows version in every problem report. OK, now, based on my preliminary check, I still cannot come up with a plausible scenario for how you lost everything in the T: volume. From my understanding of how things work with XXCOPY, the section in the T: drive which will be wiped out will be confined to the directory that you specified: "T:\Daily Essential\Equis72\". Let me start with the source (as you will see, this matter is not very significant to the subject of how you lost your data). Your command line had the "built-in" ambiguity as to the source specifier. Source: m:\2000ap~1\equis72 Destination: "t:\Daily Essential\equis72" Here, the source can be interpreted in two ways. This not-so-optimal characteristics of XXCOPY command line is a direct result of making XXCOPY fully compatible with Microsoft's XCOPY. That is, your source specifier is ambiguous and I cannot tell which of the following two ways to interpret it (nor can XXCOPY until it examines the directory at m:\2000ap~1\). If, there is a directory named "equis72" in m:\2000ap~1\, then, you are trying to copy everything inside the m:\2000ap~1\equis72\ directory (including all subdirectories) to the destination. The second possible interpretation of your command line is when there is no such directory as m:\2000ap~1\equis72\. In that case, XXCOPY will interpret (just as XCOPY would) as the following: Source base directory: m:\2000ap~1\ Lastname pattern: equis72 In this scenario, XXCOPY will try to copy a file named "equis72" in every subdirectory under the m:\2000ap~1\ directory. You should avoid such an ambiguous command line if you mean the source specifier is the name of the directory by adding the trailing backslash. But, the source directory ambiguity in this case makes no difference in how a possible damage could be done to the files in the system. That is because XXCOPY does not alter the files in the source directory unless you have the /RS or /RC switches. The damage is nearly always at the destination side. So, let us look at the destination specifier. "T:\daily Essential\equis72" In the destination side, XXCOPY does not allow any filename pattern (nor any wildcard character) which completely eliminates any possible ambiguity on the destination (we pay modest price on this by not being able to do a rename-while-copy operation with XXCOPY --- but I strongly feel that this decision is a correct one). In the destination case, the trailing backslash (unlike the source specifier counterpart) makes a relatively small difference. If the trailing backslash is present, it is equivalent to having the /I switch (create the destination directory unconditionally if not present already). Since the command used here did not have the trailing backslash in the destination specifier, it would prompt the user by "Create new directory XXXX (Yes/No) ?". In this case, the /YY switch suppressed this as if /I were present. But, in either case, the difference is minor. I'm not in the position to know whether the destination directory had been present before the doomed XXCOPY operation began. But, here's the heart of my analysis. So, let us study the two possible scenarios: 1. If the "T:\Daily Essential\equis72\" directory existed: Depending on what was in the source directory, some or nearly *ALL* of the contents in the destination directory could be "wiped out". That is by design and that is what /CLONE operation is all about. Nothing to panic except if you did not have a valid directory in the source as expected, you may see XXCOPY do its job correctly by removing all files and directories from the destination directory. But, that's nothing to complain here. 2. If "T:\Daily Essential\equis72\" directory did *NOT* exist. In this case, xxcopy will not perform any delete operation. Since there was nothing in the destination, there was nothing to delete from the destination, nor there was any file to be overwritten. Therefore, in this case, there were absolutely no files to lose. ---------- By this analysis, the worst case scenario is that you may lose some or *ALL* of the files that were already present in the T:\Daily Essential\equis72\ directory. But, under no circumstances, XXCOPY will touch anything outside of the destination directory that you have specified (this fact is based on the assumption that there is no serious bug with respect to the destination --- we are not aware of any bug of this sort). In short, the damage should have been confined to inside the destination directory. If you had misspelled the destination directory (and the wrong directory did not exist), then, no harm would be done (this would be similar to Case 2 above). So far, we have no confirmed behavior ever that the /Z function ever harmed directory contents other than the specified destination directory. I was running quite a few tests today on both WinXP and Win98SE environments and I have not observed any XXCOPY behavior that would alter contents outside the destination directory. This is the end of my analysis on the XXCOPY itself. ========================================================= Let me add my thoughts on other issues that are outside XXCOPY's activities. I'm not sure how to interpret your report. First of all, what I don't understand is what procedure you took to "slammed it shut". The proper way to terminate an ongoing XXCOPY operation is to hit Ctrl-Break. This is the best way to end a session because XXCOPY will gracefully terminate the action immediately after the handling of the current file is completed. Under no circumstances, XXCOPY will abort a file I/O operation in the middle and keep an open file open. Alternatively, you may click the Window-Close button (the top-right corner [X]), and you click [YES] to the confirming dialog. The second method is much inferior to the first (Ctrl-Break) method, because you are forcing an active program to be aborted. In some cases, such an action will leave unclosed file in the volume that may be very resilient to an attempt to remove --- I once had to reformat the volume where I had a huge allocated (corrupted file) space in order to reclaim the space. When an application program is abruptly terminated by a "brute force", then, the resulting mess (open files, etc.) should still be gracefully dealt with by the operating system (But, we have seen not so graceful aftermath). The second method still allows the device driver the chance to do a few closing procedures of pending operation on the drive. If you did not follow any of such preferred method, from your terse description of "slammed it shut", I imagine you either yanked the USB cable that connects the external drive unit to your computer, or you removed the power from the USB unit. My guess is that if you remove the USB cable connection in the middle of a disk access (as much as half such accesses may be for write access in this case), I imagine the host system will immediately notify XXCOPY that a fatal write error has occurred and XXCOPY will report the result accordingly. Since the external drive has its own USB interface and so on, I imagine that even if the physical connection is lost in the middle, the on-board microprocessor should perform a sensible thing and close the file with no serious harm to existing volume structure. (Note: since I have never designed an USB-hard disk nor do I own one, this is my educated guess). If, you removed the power from the external unit (This is the worst thing you can do to your drive), then, as far as XXCOPY is concerned, the result is nearly identical to the case of USB-cable removal. But, the data on the external volume (T:) may be corrupted. I imagine it would be very similar to removing power from a running hard disk when it is recording something. My guess is that even if the drive is busy writing to the media at the time of power removal, the loss of data on the entire volume is a very rare event. That is because the data on a disk volume is scattered to everywhere. There is a FAT section (and its backup copy), then, the root directory, and the rest of the sub directories and so on. Since the disk can write only one place at a time, when the power failure to the unit occurs, it must be at only one place. And, I imagine 99% of the cases, you will have "functioning" disk volume with a possible corrupted data structure --- that is what the scandisk utility routinely handles. It is hard to imagine that the disk with a losing power can damage the MBR or the boot sector or both of the FAT areas (or whatever applicable to the USB-disk case). In short, I estimate that it should be extremely rare to lose everything in one stroke. I wish you had used a lot more precise wording in describing your catastrophic experience. The action you took was not well explained, and the result of the damage is also so vague I cannot make much guess work based on your description. If the external hard disk behaved as if it were a completely new and clean (freshly formatted) condition, it would be very odd, in light of what you did to it (and I don't even know what you exactly did to your drive). Since you must have "aborted" in the middle (probably at the beginning), the remaining volume structure is probably half destroyed --- but probably left partially erased ???? I really need more description to reconstruct what has happened. Please read this very carefully and give us a detailed report on exactly what happened (what you did) and what is the appearance of your extranal hard disk. How many directories are there in the root directory? I apologize for this rather long reply. But, since we take the matter like this very seriously, I wanted to cover all possibilities. That is, if some important files on the drive are still there and can be retrieved, we should try that first. But, more importantly, we would like to pinpoint the cause of this event so that we can prevent the same thing from happening. I believe this is my best answer that I can give you based on your reports. If you have lost *ALL* and have nothing more to lose, that is even better for the sake of our analysis. You may try to reproduce the incident and give us all the detailed observation of what has happened. I appreciate if you make a more descriptive report. Kan Yabumoto ====================================================== At 2003-01-07 05:03, you wrote: >Hi, > >I installed 2.83.4 over the previous recent version today. > >Then I ran a normal backup. The first command on the set: > >ECHO OFF > >xxcopy m:\2000ap~1\equis72 "t:\Daily Essential\equis72" /CLONE/YY /WV0 > >I knew something was wrong pretty quickly, as the external USB drive >(t:) started writing like crazy, but the DOS window in XP was just >sitting there not giving me any output. > >So I slammed it shut as fast as I could. > >Too late. Drive t: was wiped. 120GB drive, and xxcopy was busy >cloning my entire m: drive to it. This is NOT the command, and no >other command was run except what you see above. > >This has NEVER happened before. Obviously, if it happens again, >xxcopy and I are through. I used to think this was a fantastic >program. I am not so sure now. I am in a terrible position now, >needing to redo a tremendous number of partition images, some with >incremental backups that CANNOT be duplicated. > >Any ideas why xxcopy went xxcrazy? > >Best, > >Yuku
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.