How does XXCOPY generate long filenames from 8.3 files copied over with xxcopy16

I am trying to backup a fresh install off Win98se using xxcopy and
xxcopy16.

1. I ran the command xxcopy c: d: /clone to copy all my files over to
D (save drive, extended partition) drive.

2. Then I reformatted C and using a Windows startup boot disk I ran
xcopy16 d: c: /clone .

3. Rebooted and Windows came up.

4. From the "run" menu in Windows I then ran xxcopy d: c: /nl /s .
This converted a majority of the 8.3 names to Windows longnames.

Things were not as perfect as I hoped but I continued on backing
up the files on D to a CD. Selected all the files on D from Windows
and copied them over my home network to my desktop and burned a CD.

To verify I could use the CD I reformatted "C" and used
xxcopy16 e: c: /clone .

This ran copying almost all the files. Get a "insufficient memory" error
and reran xxcopy16 e: c: /clone again to get the rest of the files.

Boorted into Windows and from the "run" option did the command
xxcopy e: c: /nl /s . Hardly any perhaps none of the files were
renamed to the longfilename.

This leads me to my question of "How does XXCOPY generate
long filenames from 8.3 files copied over with xxcopy16 ?"

Randy

Thanks Kan for the info especially for the difference between the
"c:" and the "c:\" syntax.

I guess in a very loose sense I am trying to clone Windows on "C:\"
to "C:\" with a file backup in the middle..

But I do not think what I was trying to do was actually cloning.
I am trying to backup a fresh Win98se install somehow so
that when my daughter crashes the system I could easily
recover. This is a laptop without a cd burner so I wanted
to copy all the files over to the D:\ partition (use xxcopy); move the files
to another computer over the network and burn a CD.

Then when needed I would copy over all the files, with long filenames,
back onto a formated "C:\" partition. This is where I am confused. At this
time I do not have Windows environment on my laptop so I cannot
use xxcopy. Your xxcopy10.htm article in the Q&A section indicates
I would use xxcopy16 to copy the 8.3 files over then boot into Windows
and use xxcopy with the "/S /nl" switches to udate the names.

But you also give two warnings. Xxcopy16 cannot handle paths
that are too long. Also needed is handling files created before running
xxcopy. You finally end with "In short, this procedure is troublesome
at best and we don't recommend it to anyone who asks this question
in the first place."

So is there a reliable process using xxcopy and or xxcopy16 to
produces a copy of a Windows system that can be archived on
a cd and then installed back on a machine which does not have
Windows already running?

Thanks for any clarification.

Randy



Kan Yabumoto <tech@xxcopy.com> wrote in message
news:4e377a72.0306251848.146ecc40@posting.google.com...
> "RNelson" <rnelson3@nc.rr.com> wrote in message
news:<6dpKa.101833$nr.6399236@twister.southeast.rr.com>...
> > I am trying to backup a fresh install off Win98se using xxcopy and
> > xxcopy16.
> >
>
> We have provided a detailed, step-by-step instruction to do a Win98SE
> cloning which I believe nearly everyone can follow.
>
> http://www.xxcopy.com/clone
>
> In the article, we specifically recommend against the use of XXCOPY16
> to clone the whole Win9x volume disk. XXCOPY16 being a pure 16-bit
> application without any low-level I/O tricks to perform (no sector
> access directly --- that is why the article suggest the use of
> FORMAT.COM and FDISK.EXE to do few extra things that XXCOPY/XXCOPY16
> do not perform).
>
> 1. using XXCOPY16, you may not be able to directories/files whose
> total pathname exceeds the 79-character limit (this is a DOS limit
> and if you try to access a file with a longer path, DOS (not
> the application) crashes). XXCOPY16's provision for this issue
> is simply not to process files whose path exceeds the DOS limit.
>
> 2. XXCOPY16 lives in the 640KB DOS world. It may run out of memory
> in a big job.
>
> 3. we simply see no advantage using XXCOPY16 for the system disk
> cloning.
>
> > 1. I ran the command xxcopy c: d: /clone to copy all my files over to
> > D (save drive, extended partition) drive.
>
> We strongly recommend *NOT* to use a "sloppy" command line like that.
>
> xxcopy c: d: /clone
>
> If you do not see a difference between the following two lines,
>
> xxcopy c: d: /clone
> xxcopy c:\ d:\ /clone
>
> then, you should not use the /CLONE command at all. Use /BACKUP
> command which is much safer and accomplish nearly the same thing.
>
> We explain why this is bad in the following article:
>
> http://www.xxcopy.com/xxcopy22.htm
>
> > 2. Then I reformatted C and using a Windows startup boot disk I ran
> > xcopy16 d: c: /clone .
>
> > 3. Rebooted and Windows came up.
> >
> > 4. From the "run" menu in Windows I then ran xxcopy d: c: /nl /s .
> > This converted a majority of the 8.3 names to Windows longnames.
>
> Here, if you want to restore the LFN for an SFN-only directory,
> the correct way to do is:
>
> xxcopy \src\ \dst\ /s /nl
>
> (Here, \src\ is where the original directory with the LFN is and
> \dst\ is where the SFN-only directory is).
>
> Again, I strongly suggest that you stop using a bare drive-letter-only
> designation for the source or destination specifier.
>
> If you open up a DOS Box on a Windows, it often gives you a current
> directory that is not at the root level. As a matter of fact,
> the problem Randy had may be exactly that.
>
> Again, the following commands are quite different:
>
> xxcopy d: c: /nl /s
> xxcopy d:\ c:\ /nl /s
>
> (they could be the same if the current directory of C: and D:
> are both at the root level. But, making such assumption is
> a bad idea.)
>
> > Things were not as perfect as I hoped but I continued on backing
> > up the files on D to a CD. Selected all the files on D from Windows
> > and copied them over my home network to my desktop and burned a CD.
> >
> > To verify I could use the CD I reformatted "C" and used
> > xxcopy16 e: c: /clone .
>
> Again, anyone reading this message, please take note of
> my recommendation that a bare drive letter designation is
> a bad idea E: C: could be at any directory inside the
> respective volume and /CLONE command is too dangerous.
> (I suggest the use of /BACKUP in lieu of /CLONE if you
> are not 100% sure of what is the backslash after the colon
> does to you).
>
> > This ran copying almost all the files. Get a "insufficient memory" error
> > and reran xxcopy16 e: c: /clone again to get the rest of the files.
>
> You may just run the same /CLONE command which will run the
> same command (but skips what the previous has completed).
> So, it is not a big deal. XXCOPY16 is a 16-bit (DOS) program
> which must live in the small 640KB memory constraint. While
> XXCOPY16's usage of memory is not the most efficient, there is
> a limit in any resource. when we wrote the predecessor of XXCOPY16,
> we never had hard disk as large as 1 GB and the way it allocated
> memory was sufficient. Again, I strongly suggest the use of
> XXCOPY (the 32-bit version) for a relatively large job.
>
> > Boorted into Windows and from the "run" option did the command
> > xxcopy e: c: /nl /s . Hardly any perhaps none of the files were
> > renamed to the long filename.
>
> My guess is again, E: and C: are not defaulting to the root
> directory.
>
> > This leads me to my question of "How does XXCOPY generate
> > long filenames from 8.3 files copied over with xxcopy16 ?"
>
> The /NL command is not very complicated. It identifies the
> file in the source and the destination using the common
> SFN. Then, the file in the destination will be renamed to
> the string that is attached to the source file (LFN).
>
> Since the /NL operation does not rely on anything specific to
> what XXCOPY16 does, you may retrofit an LFN to a file that
> was copied by any 16-bit program using the 8.3 name.
>
> ----------------------
>
> I'm not sure why Randy is trying to do it the hard way.
> The /CLONE article gives a clear direction.
>
> http://www.xxcopy.com/clone
>
> Kan Yabumoto
> The author of XXCopy.