[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread[>>]
Number : 55 Date : 2001-05-17 Author : Kan Yabumoto Subject : Re: Using XXCOPY to Back Up to CDRW Size(KB) : 3
Let me add my comments only on the relevant section. If you want to reconstruct the whole story, please refer to Jim's original posts. At 2001-05-16 19:15, Jim Witherspoon wrote: >Some thoughts on using XXCOPY to back up to CDRW. I am just going from >memory here, so if I make any misstatements of fact, please correct me! ,,, The LFN problem - the way I understand it, files copied to CDs are limited >to 64 character filenames instead of 256 characters allowed by Windows. I >have run into this limitation while using Easy CD Creator, but I haven't >used DirectCD, so I don't know if the same problem exists with DirectCD. In my opinion, the maximum character count allowed for a filename (250 some character) should not be viewed as a license to create an extremely long filenames. Since the absolute maximum combined-path length is some 255 characters (give plus one or minus one --- even in this business, the precise number escapes my head all the time) for Windows LFN, if you create a near-maximum filename, you cannot conveniently move around this file into some other subdirectories which often add a few levels of subdirectories. I have seen many MP3 files downloaded from Napster go extreme on this. I suppose those who name these files are not really computer-literate. The 64-character limit introduced by the Jolliet standard (a CDR format) seems to make more sense. I have noted that EasyCD (or was it DirectCD?) goes through the filename truncation (to conform to the 64 characters) in the preparation stage of CD creation. That make a lot of sense. One should make such conversion not just for a temporary measure but observe some sane limit such as the 64-character limit as a good housekeeping rule. >The SFN problem - if I remember correctly, SFNs aren't copied to CDRW at >all. Only the LFN is preserved (with the 64-character limitation). > >Kan has laid out an ingenious method of duplicating a directory tree, >including the same files, LFNs, SFNs, and date/time stamps - except that all >the "files" in the duplicate structure are zero-byte files! This duplicate >tree could be kept current pretty easily. You could use this duplicate tree >to save LFNs, SFNs, and date/time stamps before you back up to CDs. Then, >when you restore the files from CD, you could use this duplicate tree to >restore the SFNs, by using the /NS switch. Am I right about this, Kan? Yes. Your usage of the zero-length file is one of many cases I have anticipated. The use of the /NS switch is correct in this instance. I have not used the /NS switch myself yet other than for testing the feature under an artificial environment. As you can see, the zero-length file technique is not designed to serve a "catalog" for a volume, albeit sometimes useful. That is why we need a true catalog file which represent any directory with all pertinent directory info including LFN/SFN, etc. and the catalog file itself is portable as a regular file. The use would not be limited to the LFN/SFN restoration, but for a construction of a virtual volume based on a removable-media drive (floppy/CDR) without which the spanned incremental backup scheme would be difficult to implement. That will be a next major feature enhancement. Kan Yabumoto ========================================================================
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.