A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » General Hardware & Peripherals » Storage (alternative)
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

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



 
 
Thread Tools Display Modes
  #1  
Old June 25th 03, 11:18 PM
RNelson
external usenet poster
 
Posts: n/a
Default 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


  #2  
Old June 26th 03, 05:14 AM
RNelson
external usenet poster
 
Posts: n/a
Default

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 wrote in message
om...
"RNelson" wrote in message

.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.



 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
System Beeps - Five Beeps (One long, two short, high pitch, low pitch) Huw E General 3 January 30th 04 04:49 AM
System Beeps - Five Beeps (One long, two short, high pitch, low pitch) Huw E General 0 January 28th 04 11:58 PM
Complete newbie question(s) (long) Chris Martin Overclocking AMD Processors 1 December 27th 03 12:04 AM
Get the Serial Number with Visual Basic Michael Wittmann General 15 November 15th 03 07:03 PM
Burning long filenames with linux walt moffett Cdr 1 July 19th 03 10:33 AM


All times are GMT +1. The time now is 11:53 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.