[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread[>>]
Number : 65 Date : 2001-05-17 Author : Kan Yabumoto Subject : Re: xxcopy switches, etc. Size(KB) : 5
Dear Joseph: Let me follow up Jim's response. I think we have to go back to your original question with the filename such as techsp~1.doc. The examples that I gave you which you cited again (shown below once more) were chosen to address the case where you said "with the long filename whacked...". The example filenames I chose MYLONG~1 (MYLONG~1) and MYLONG~2 (MYLONG~2) are typical case of what you just described. Here, you are apparently confused by the notation I just introduced without fully explaining what I meant by the two name (one in parenthesis). That was, one LFN followed by the corresponding SFN in parenthesis. In the particular section, when I showed MYLONG~1 (MYLONG~1), that is where the filename happens to be in the 8.3 format, and therefore (as Jim Witherspoon correctly pointed out) what I meant was LFN = MYLONG~1 and SFN = MYLONG~1 (both are identical). You are then asking me a case for MYLONG~2 (MYLONG~1). You are very confused here. If you create a file with LFN = MYLONG~1 which qualifies for an SFN, then, you just can't have a different ending like SFN = MYLONG~2. >one of your examples. > > > Here's another case >Before the copy (XXCOPY \SRC \DST) > > Source Destination > ----------------------------------------------------------- > LFN (SFN) LFN (SFN) > MYLONG~1 (MYLONG~1) MYLONG~1 (MYLONG~1) > MYLONG~2 (MYLONG~2) MYLONG~2 (MYLONG~2) > >After the copy > > Source Destination > ----------------------------------------------------------- > LFN (SFN) LFN (SFN) > MYLONG~1 (MYLONG~1) MYLONG~1 (MYLONG~1) > MYLONG~2 (MYLONG~2) MYLONG~2 (MYLONG~2) Again, this example that I gave you was to explain what was your orignal "whacked" directory where the LFN are stripped from those files (and therefore, these files are all basically SFN only names (see LFN and SFN are the same here). I think this is the case you had in your whacked drive and I was trying to show you the net effect of copying the files using XXCOPY whether you use /NX or /NX0, the net effect is the same (i.e., your fear of wrong file being overwritten by XXCOPY to be unfounded). >You are making the assumption that the files in a directory are copied in >alphabetical order on LFN. Is this correct? It would be >great if so, and would be the end of my worries here. No. These are nothing to do with the alphabetical order (again, you are too contaminated by the silly Explorer's idiosyncrasies where a directory contents are often shown in alphabetic order (then, when Explorer starts copying in full speed, it performs the copy by the "native" order --- not the artificial, alphabetic order, thank God!). >Otherwise, what can happen is a file MYLONG~2 (MYLONG~2) gets copied >first and becomes MYLONG~2 (MYLONG~1). What would then happen to >the following MYLONG~1 as it tries to copy the files in "file number" >order, if for some reason the MYLONG~2 has a lower file number? Here, your sentence reveals the source of your confusion. When a directory does not have a file MYLONG~1 and there exists a file by MYLONG~2 (MYLONG~2), then, copying a file MYLONG~2 (MYLONG~2) will not trigger the SFN-synthesizing routine. It simply overwrites MYLONG~2 (MYLONG~2). On the other hand, when you copy a file with a longname (e.g., My_Long_Name) whose name would create SFN = MYLONG~1, to the directory, then, yes, the destination will have My_Long_Name with the SFN = MYLONG~1. Probably, you are worrying that a file in the destination with MYLONG~1 (MYLONG~1) would be wiped out when a file like My_Long_Name (MYLONG~1) is being copied to the directory. The answer is no. If you use COPY, XCOPY, or XXCOPY (with /NX or /NX0), when you copy MY_Long_Name (MYLONG~1) to the destination with MYLONG~1 (MYLONG~1), the new file will be named as My_Long_Name (MYLONG~2). This is true even with the /NX switch!!! The /NX operation performed by XXCOPY is to first perform the ordinary file-copy operation like using any other file-copy utility. After a successful copy operation (overwriting whatever file which should be legitimately overwritten), XXCOPY will check to see whether the SFN for the file happens to match the corresponding SFN in the source. If they match, no further action needed. If they don't match *AND* the /NX switch is specified, then, XXCOPY will try its best to rename the SFN. If the desired SFN is already taken by an existing object (file or even a subdirectory) in the directory, then, it won't bother the renaming --- here, you must have worried that in order to take the SFN, XXCOPY would delete the existing file/directory (you used the word "overwriting" which is essentially the same). No, that would be too drastic. Remember, XXCOPY's SFN-preserving feature is good only when the circumstance allows it to proceed. If you use XXCOPY more, you will realize how "allergic" XXCOPY is to any destructive (delete, and overwrite) operation. It gives you plenty (probably too many) confirmation prompts before a deletion. We are really paranoia on undesired deletion. So, XXCOPY would not do a nasty thing like deleting an existing file quietly simply to achieve the not-so-important goal of the /NX operation? If you get to know XXCOPY better, this is no brainer. > > Please note that when you have a filename such as >MYLONG~1 (MYLONG~1) that is a result of previous file-copy >operations which went pretty bad < > >Right. The name is trashed, but I wish to retain the content of both >files. When filenames are fully messed up like this, there is no clear cut answer. The best way probably is the /NL switch: XXCOPY \src \dst /NL at the earliest possible time while the source directory is still available and the contents still intact. In this case, again, if the renaming is not possible due to a conflict of filenames, then, XXCOPY would not take away a name from existing object; it rather not accomplish the job than do more harm. Kan Yabumoto ========================================================================
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.