C
cindykapitan
A good backup program for win98SE needed. It should be able to backup
to an external CD writer from HP. Please help by reccommending one.
to an external CD writer from HP. Please help by reccommending one.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
B
Brian A.
Cindy,
I use Backup MyPC by Stomp (formerly Backup Exec. by Veritas). It backs up to any
media and also backs up the registry.
Others will be along with their thoughts/suggestions.
--
Brian A.
Jack of all trades, Master of none. One can never truly be a master as there is
always more to learn.
I use Backup MyPC by Stomp (formerly Backup Exec. by Veritas). It backs up to any
media and also backs up the registry.
Others will be along with their thoughts/suggestions.
--
Brian A.
Jack of all trades, Master of none. One can never truly be a master as there is
always more to learn.
A
Angelo Campanella
cindykapitan said:A good backup program for win98SE needed. It should be able to backup
to an external CD writer from HP. Please help by reccommending one.
I have solved that problem by having a second hard drive that can be connected as
a storage medium. I then use XXCOPY to make a clone of my existing hard drive.
The spare drive must have a capacity same or larger than the space you are
occupying as the regular hard drive. After copying the cloned version back onto
the hard drive (or another you want to use as the main drive), Windows 98 can be
self- booted from that after about two or three trys at same. W98 seems to
"heal" or "grow" itself to work OK that way!
Angelo Campanella
A
Angelo Campanella
PCR said:You should investigate why it takes 2/3 boots to boot once, after an
XXCopy. Can it be you copy the swap file (Win386.swp) with it? I have
read that should not be copied. It will generate anew when you boot to
Windows.
Perhaps true. I just did it the really dumb and simple way; Copy and Run!
Angelo Campanella
P
PCR
Well, you must investigate. Let me see whether I have a site...
http://www.xxcopy.com/
What about the XXCopy site, itself? Surely there are FAQs there?
I also know XXCopy suffers of Short File Name mishaps. That is, if there
are two or more names such as "Progra~1" & "Progra~2", there is a
possibility they are switched in the copy. They will get the correct
LFN, but "can" get switched in the SFN. This would only matter if
something referred to the SFN.
However, I can't see how three re-boots could fix such a thing.
But never copy your Swap File that way. That might have done it, I
think. Let Windows regenerate the Swap File (Win386.swp) when you boot
the copy.
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
| PCR wrote:
|
| > You should investigate why it takes 2/3 boots to boot once, after an
| > XXCopy. Can it be you copy the swap file (Win386.swp) with it? I
have
| > read that should not be copied. It will generate anew when you boot
to
| > Windows.
|
|
| Perhaps true. I just did it the really dumb and simple way; Copy and
Run!
|
|
| Angelo Campanella
|
http://www.xxcopy.com/
What about the XXCopy site, itself? Surely there are FAQs there?
I also know XXCopy suffers of Short File Name mishaps. That is, if there
are two or more names such as "Progra~1" & "Progra~2", there is a
possibility they are switched in the copy. They will get the correct
LFN, but "can" get switched in the SFN. This would only matter if
something referred to the SFN.
However, I can't see how three re-boots could fix such a thing.
But never copy your Swap File that way. That might have done it, I
think. Let Windows regenerate the Swap File (Win386.swp) when you boot
the copy.
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
| PCR wrote:
|
| > You should investigate why it takes 2/3 boots to boot once, after an
| > XXCopy. Can it be you copy the swap file (Win386.swp) with it? I
have
| > read that should not be copied. It will generate anew when you boot
to
| > Windows.
|
|
| Perhaps true. I just did it the really dumb and simple way; Copy and
Run!
|
|
| Angelo Campanella
|
R
Rod Speed
Well, you must investigate. Let me see whether I have a site...
http://www.xxcopy.com/
What about the XXCopy site, itself? Surely there are FAQs there?
I also know XXCopy suffers of Short File Name mishaps. That is,
if there are two or more names such as "Progra~1" & "Progra~2",
there is a possibility they are switched in the copy. They will get
the correct LFN, but "can" get switched in the SFN. This would
only matter if something referred to the SFN.
You've mangled that utterly. Its the standard xcopy that has that
particularly problem and xxcopy that ensures that doesnt happen.
However, I can't see how three re-boots could fix such a thing.
It cant, and there is nothing to be 'fixed' in that area anyway.
But never copy your Swap File that
way. That might have done it, I think.
Unlikely that 3 reboots would fix that either.
P
PCR
|
| |
| > Well, you must investigate. Let me see whether I have a site...
| > http://www.xxcopy.com/
| > What about the XXCopy site, itself? Surely there are FAQs there?
|
| > I also know XXCopy suffers of Short File Name mishaps. That is,
| > if there are two or more names such as "Progra~1" & "Progra~2",
| > there is a possibility they are switched in the copy. They will get
| > the correct LFN, but "can" get switched in the SFN. This would
| > only matter if something referred to the SFN.
|
| You've mangled that utterly. Its the standard xcopy that has that
| particularly problem and xxcopy that ensures that doesnt happen.
No. I did not. Gosh, I can't recall his name, but the author of XXCopy
said it is a Windows problem. Harper even posted that Explorer itself
suffers of it, not just DOS. It is as I said. LFNs will still be
assigned to the proper file, but SFNs can switch. Sorry, I have no quick
way to find the URL Harper posted about it.
But, create say nine files in one folder that will get names "Progra~1"
through "Progra~9". Then try the copy in DOS & in Explorer.
|
| > However, I can't see how three re-boots could fix such a thing.
|
| It cant, and there is nothing to be 'fixed' in that area anyway.
|
| > But never copy your Swap File that
| > way. That might have done it, I think.
|
| Unlikely that 3 reboots would fix that either.
It isn't an experiment I will do. However, Angelo might, when next he
does his XXCopy. (He's already done it the wrong way.) Copying the Swap
File that way is the most often heard prohibition about Xcopy32, XXCopy
& even an Explorer copy.
|
| > Let Windows regenerate the Swap File
| > (Win386.swp) when you boot the copy.
|
|
| > | > | PCR wrote:
| > |
| > | > You should investigate why it takes 2/3 boots to boot once,
after an
| > | > XXCopy. Can it be you copy the swap file (Win386.swp) with it? I
| > have
| > | > read that should not be copied. It will generate anew when you
boot
| > to
| > | > Windows.
| > |
| > |
| > | Perhaps true. I just did it the really dumb and simple way; Copy
and
| > Run!
| > |
| > |
| > | Angelo Campanella
| > |
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
| |
| > Well, you must investigate. Let me see whether I have a site...
| > http://www.xxcopy.com/
| > What about the XXCopy site, itself? Surely there are FAQs there?
|
| > I also know XXCopy suffers of Short File Name mishaps. That is,
| > if there are two or more names such as "Progra~1" & "Progra~2",
| > there is a possibility they are switched in the copy. They will get
| > the correct LFN, but "can" get switched in the SFN. This would
| > only matter if something referred to the SFN.
|
| You've mangled that utterly. Its the standard xcopy that has that
| particularly problem and xxcopy that ensures that doesnt happen.
No. I did not. Gosh, I can't recall his name, but the author of XXCopy
said it is a Windows problem. Harper even posted that Explorer itself
suffers of it, not just DOS. It is as I said. LFNs will still be
assigned to the proper file, but SFNs can switch. Sorry, I have no quick
way to find the URL Harper posted about it.
But, create say nine files in one folder that will get names "Progra~1"
through "Progra~9". Then try the copy in DOS & in Explorer.
|
| > However, I can't see how three re-boots could fix such a thing.
|
| It cant, and there is nothing to be 'fixed' in that area anyway.
|
| > But never copy your Swap File that
| > way. That might have done it, I think.
|
| Unlikely that 3 reboots would fix that either.
It isn't an experiment I will do. However, Angelo might, when next he
does his XXCopy. (He's already done it the wrong way.) Copying the Swap
File that way is the most often heard prohibition about Xcopy32, XXCopy
& even an Explorer copy.
|
| > Let Windows regenerate the Swap File
| > (Win386.swp) when you boot the copy.
|
|
| > | > | PCR wrote:
| > |
| > | > You should investigate why it takes 2/3 boots to boot once,
after an
| > | > XXCopy. Can it be you copy the swap file (Win386.swp) with it? I
| > have
| > | > read that should not be copied. It will generate anew when you
boot
| > to
| > | > Windows.
| > |
| > |
| > | Perhaps true. I just did it the really dumb and simple way; Copy
and
| > Run!
| > |
| > |
| > | Angelo Campanella
| > |
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
R
Rod Speed
PCR said:| PCR <[email protected]> wrote
| > Well, you must investigate. Let me see whether I have a site...
| > http://www.xxcopy.com/
| > What about the XXCopy site, itself? Surely there are FAQs there?
| > I also know XXCopy suffers of Short File Name mishaps. That is,
| > if there are two or more names such as "Progra~1" & "Progra~2",
| > there is a possibility they are switched in the copy. They will get
| > the correct LFN, but "can" get switched in the SFN. This would
| > only matter if something referred to the SFN.
| You've mangled that utterly. Its the standard xcopy that has that
| particularly problem and xxcopy that ensures that doesnt happen.
No. I did not.
Yes you did, utterly.
Gosh, I can't recall his name, but the author
of XXCopy said it is a Windows problem.
And YOU claimed above that its an xxcopy problem which it aint.
He says very explicitly indeed that xxcopy FIXES that problem.
http://www.xxcopy.com/xxcopy03.htm
Harper even posted that Explorer itself suffers of it, not just DOS.
I didnt even mention dos.
It is as I said.
Nope, not as far as xxcopy having the problem it aint.
LFNs will still be assigned to the proper file, but SFNs can switch.
Not when xxcopy is used.
Sorry, I have no quick way to find the URL Harper posted about it.
But, create say nine files in one folder that will get names "Progra~1"
through "Progra~9". Then try the copy in DOS & in Explorer.
Pity about what happens when xxcopy is used. THATS
what you mangled utterly. It FIXES that problem by
ensuring that the short and long file name pairs are
the same on the source and the destination.
| > However, I can't see how three re-boots could fix such a thing.
| It cant, and there is nothing to be 'fixed' in that area anyway.
| > But never copy your Swap File that
| > way. That might have done it, I think.
| Unlikely that 3 reboots would fix that either.
It isn't an experiment I will do. However, Angelo might, when
next he does his XXCopy. (He's already done it the wrong way.)
Copying the Swap File that way is the most often heard
prohibition about Xcopy32, XXCopy & even an Explorer copy.
Thats for a different reason. Win just wont let you copy the
swap file and so the copy aborts when you get to that file.
And the xxcopy documentation doesnt say its a problem.
http://www.xxcopy.com/xxcopy10.htm
In fact it wont copy it and that will cause an automatic
recreation of that file when the clone is booted.
P
PCR
Ah, Kan Yabumoto! This is one bright guy, Yabumoto is. Reading the URLs
you provided, I understand the problem very likely is & always was
solved in the case of XXCopy going to an empty folder, provided the OS
is pure. It is when SFNs already exist in the destination folder that a
problem may arise. The problem with mixed OS's, is that they SFNs
differently. There are other cautions mentioned in the URL trail you
posted, but I think it is not involved in this situation.
However, there are two versions of XXCopy. The one that runs in "true"
DOS may not be as capable as the 32-bit version.
Yet this is likely not the reason cindykapitan needs to boot thrice to
boot once. But I never said it was! I take you at your word that XXCopy
also handles the Swap File correctly. I only offered that as a
possibility.
So, why does she need to boot thrice?
.......Start...of exchange between me & him......
| Hi, PCR;
|
| XXCOPY's /NX operation (it is a default setting) tries to preserve the
| SFN that is associated with the source file at the destination file
| as much as possible. Since this feature is only an added "bonus"
| when XXCOPY finds a situation in the destination which does not
| easily accommodate the desired outcome, it gives up the effort on
| that file. There are a number of scenarios where the /NX operation
| fails. For example, when there is another file in the destination
| which already has the desired file name, then, XXCOPY will not try
| to vacate the desired SFN by renaming the existing one. Another
| scenario is when the source or destination volume is controlled by
| both Win9X/ME and NT/2K/XP families of Windows (e.g., with a dual-boot
| system). While the first four SFN names are synthesized using the
| same scheme (starting with XXXXXX~1, XXXXXX~2, .... XXXXXX~4) by both
| the 9X/ME family and the NT family, the NT-family Windows switches
| the algorithm using a 4-digit hexadecimal hash value (e.g., XXABCD~1)
| to avoid excessive SFN collisions. The following article explains
| the details:
|
| http://www.xxcopy.com/xxcopy08.htm
|
| Another notable case is with the file system for the CD-R/W
| (packet-write) volume such as InCD and DirectCD. The file system
| for CD-R/W uses a totally different scheme to assign the SFN.
|
| Since XXCOPY uses a combination of standard file I/O API functions
| iteratively to manipulate the SFN in order to preserve the
| SFN (rather than using direct low-level device I/O operations),
| XXCOPY will give up the /NX operation when the SFN preservation is
| not possible.
|
| Therefore, it is true that XXCOPY does not always succeed in
| preserving the SFN. However, we believe it is not critical in
| most situations (except when one tries to save the whole system
| volume into a CD-R/W volume and hopes to maintain the exact
| 8.3-name based referencing --- often found in the system registry).
| Typically, the most common place to encounter a massive SFN-collisions
| is in the cookies directory where the web browser (e.g., IE and
Mozilla)
| saves cookies using a series of files whose name share the
| same beginning. Since the cookie files are always referenced by
| their LFN name, the SFN preservation for those files should not
| be critical.
|
| The most important SFN that should be preserved is the common
| ones such as "C:\Program Files\", "C:\Documents and Settings\".
|
| Kan Yabumoto
| The author of XXCopy
| ====================================================================
| > Mr. Yabumoto, I thought I read somewhere that even XXCopy has a
problem
| > with Short File Names (8+3), after the tilde (~), if two in the same
| > folder differ only by the tilde portion. Is that true?
| >
| > --
| > Thanks & Good Luck,
| > PCR
| > (e-mail address removed)
.......End...of exchange between me & him......
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
|
| |
| > | > Well, you must investigate. Let me see whether I have a site...
| > | > http://www.xxcopy.com/
| > | > What about the XXCopy site, itself? Surely there are FAQs there?
|
| > | > I also know XXCopy suffers of Short File Name mishaps. That is,
| > | > if there are two or more names such as "Progra~1" & "Progra~2",
| > | > there is a possibility they are switched in the copy. They will
get
| > | > the correct LFN, but "can" get switched in the SFN. This would
| > | > only matter if something referred to the SFN.
|
| > | You've mangled that utterly. Its the standard xcopy that has that
| > | particularly problem and xxcopy that ensures that doesnt happen.
|
| > No. I did not.
|
| Yes you did, utterly.
|
| > Gosh, I can't recall his name, but the author
| > of XXCopy said it is a Windows problem.
|
| And YOU claimed above that its an xxcopy problem which it aint.
| He says very explicitly indeed that xxcopy FIXES that problem.
| http://www.xxcopy.com/xxcopy03.htm
|
| > Harper even posted that Explorer itself suffers of it, not just DOS.
|
| I didnt even mention dos.
|
| > It is as I said.
|
| Nope, not as far as xxcopy having the problem it aint.
|
| > LFNs will still be assigned to the proper file, but SFNs can switch.
|
| Not when xxcopy is used.
|
| > Sorry, I have no quick way to find the URL Harper posted about it.
|
| > But, create say nine files in one folder that will get names
"Progra~1"
| > through "Progra~9". Then try the copy in DOS & in Explorer.
|
| Pity about what happens when xxcopy is used. THATS
| what you mangled utterly. It FIXES that problem by
| ensuring that the short and long file name pairs are
| the same on the source and the destination.
|
| > | > However, I can't see how three re-boots could fix such a thing.
|
| > | It cant, and there is nothing to be 'fixed' in that area anyway.
|
| > | > But never copy your Swap File that
| > | > way. That might have done it, I think.
|
| > | Unlikely that 3 reboots would fix that either.
|
| > It isn't an experiment I will do. However, Angelo might, when
| > next he does his XXCopy. (He's already done it the wrong way.)
| > Copying the Swap File that way is the most often heard
| > prohibition about Xcopy32, XXCopy & even an Explorer copy.
|
| Thats for a different reason. Win just wont let you copy the
| swap file and so the copy aborts when you get to that file.
|
| And the xxcopy documentation doesnt say its a problem.
| http://www.xxcopy.com/xxcopy10.htm
|
| In fact it wont copy it and that will cause an automatic
| recreation of that file when the clone is booted.
|
| > | > Let Windows regenerate the Swap File
| > | > (Win386.swp) when you boot the copy.
|
|
| > | > | > | > | PCR wrote:
| > | > |
| > | > | > You should investigate why it takes 2/3 boots to boot once,
| > after an
| > | > | > XXCopy. Can it be you copy the swap file (Win386.swp) with
it? I
| > | > have
| > | > | > read that should not be copied. It will generate anew when
you
| > boot
| > | > to
| > | > | > Windows.
| > | > |
| > | > |
| > | > | Perhaps true. I just did it the really dumb and simple way;
Copy
| > and
| > | > Run!
| > | > |
| > | > |
| > | > | Angelo Campanella
| > | > |
| >
| > --
| > Thanks or Good Luck,
| > There may be humor in this post, and,
| > Naturally, you will not sue,
| > should things get worse after this,
| > PCR
| > (e-mail address removed)
| >
| >
|
|
you provided, I understand the problem very likely is & always was
solved in the case of XXCopy going to an empty folder, provided the OS
is pure. It is when SFNs already exist in the destination folder that a
problem may arise. The problem with mixed OS's, is that they SFNs
differently. There are other cautions mentioned in the URL trail you
posted, but I think it is not involved in this situation.
However, there are two versions of XXCopy. The one that runs in "true"
DOS may not be as capable as the 32-bit version.
Yet this is likely not the reason cindykapitan needs to boot thrice to
boot once. But I never said it was! I take you at your word that XXCopy
also handles the Swap File correctly. I only offered that as a
possibility.
So, why does she need to boot thrice?
.......Start...of exchange between me & him......
| Hi, PCR;
|
| XXCOPY's /NX operation (it is a default setting) tries to preserve the
| SFN that is associated with the source file at the destination file
| as much as possible. Since this feature is only an added "bonus"
| when XXCOPY finds a situation in the destination which does not
| easily accommodate the desired outcome, it gives up the effort on
| that file. There are a number of scenarios where the /NX operation
| fails. For example, when there is another file in the destination
| which already has the desired file name, then, XXCOPY will not try
| to vacate the desired SFN by renaming the existing one. Another
| scenario is when the source or destination volume is controlled by
| both Win9X/ME and NT/2K/XP families of Windows (e.g., with a dual-boot
| system). While the first four SFN names are synthesized using the
| same scheme (starting with XXXXXX~1, XXXXXX~2, .... XXXXXX~4) by both
| the 9X/ME family and the NT family, the NT-family Windows switches
| the algorithm using a 4-digit hexadecimal hash value (e.g., XXABCD~1)
| to avoid excessive SFN collisions. The following article explains
| the details:
|
| http://www.xxcopy.com/xxcopy08.htm
|
| Another notable case is with the file system for the CD-R/W
| (packet-write) volume such as InCD and DirectCD. The file system
| for CD-R/W uses a totally different scheme to assign the SFN.
|
| Since XXCOPY uses a combination of standard file I/O API functions
| iteratively to manipulate the SFN in order to preserve the
| SFN (rather than using direct low-level device I/O operations),
| XXCOPY will give up the /NX operation when the SFN preservation is
| not possible.
|
| Therefore, it is true that XXCOPY does not always succeed in
| preserving the SFN. However, we believe it is not critical in
| most situations (except when one tries to save the whole system
| volume into a CD-R/W volume and hopes to maintain the exact
| 8.3-name based referencing --- often found in the system registry).
| Typically, the most common place to encounter a massive SFN-collisions
| is in the cookies directory where the web browser (e.g., IE and
Mozilla)
| saves cookies using a series of files whose name share the
| same beginning. Since the cookie files are always referenced by
| their LFN name, the SFN preservation for those files should not
| be critical.
|
| The most important SFN that should be preserved is the common
| ones such as "C:\Program Files\", "C:\Documents and Settings\".
|
| Kan Yabumoto
| The author of XXCopy
| ====================================================================
| > Mr. Yabumoto, I thought I read somewhere that even XXCopy has a
problem
| > with Short File Names (8+3), after the tilde (~), if two in the same
| > folder differ only by the tilde portion. Is that true?
| >
| > --
| > Thanks & Good Luck,
| > PCR
| > (e-mail address removed)
.......End...of exchange between me & him......
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
|
| |
| > | > Well, you must investigate. Let me see whether I have a site...
| > | > http://www.xxcopy.com/
| > | > What about the XXCopy site, itself? Surely there are FAQs there?
|
| > | > I also know XXCopy suffers of Short File Name mishaps. That is,
| > | > if there are two or more names such as "Progra~1" & "Progra~2",
| > | > there is a possibility they are switched in the copy. They will
get
| > | > the correct LFN, but "can" get switched in the SFN. This would
| > | > only matter if something referred to the SFN.
|
| > | You've mangled that utterly. Its the standard xcopy that has that
| > | particularly problem and xxcopy that ensures that doesnt happen.
|
| > No. I did not.
|
| Yes you did, utterly.
|
| > Gosh, I can't recall his name, but the author
| > of XXCopy said it is a Windows problem.
|
| And YOU claimed above that its an xxcopy problem which it aint.
| He says very explicitly indeed that xxcopy FIXES that problem.
| http://www.xxcopy.com/xxcopy03.htm
|
| > Harper even posted that Explorer itself suffers of it, not just DOS.
|
| I didnt even mention dos.
|
| > It is as I said.
|
| Nope, not as far as xxcopy having the problem it aint.
|
| > LFNs will still be assigned to the proper file, but SFNs can switch.
|
| Not when xxcopy is used.
|
| > Sorry, I have no quick way to find the URL Harper posted about it.
|
| > But, create say nine files in one folder that will get names
"Progra~1"
| > through "Progra~9". Then try the copy in DOS & in Explorer.
|
| Pity about what happens when xxcopy is used. THATS
| what you mangled utterly. It FIXES that problem by
| ensuring that the short and long file name pairs are
| the same on the source and the destination.
|
| > | > However, I can't see how three re-boots could fix such a thing.
|
| > | It cant, and there is nothing to be 'fixed' in that area anyway.
|
| > | > But never copy your Swap File that
| > | > way. That might have done it, I think.
|
| > | Unlikely that 3 reboots would fix that either.
|
| > It isn't an experiment I will do. However, Angelo might, when
| > next he does his XXCopy. (He's already done it the wrong way.)
| > Copying the Swap File that way is the most often heard
| > prohibition about Xcopy32, XXCopy & even an Explorer copy.
|
| Thats for a different reason. Win just wont let you copy the
| swap file and so the copy aborts when you get to that file.
|
| And the xxcopy documentation doesnt say its a problem.
| http://www.xxcopy.com/xxcopy10.htm
|
| In fact it wont copy it and that will cause an automatic
| recreation of that file when the clone is booted.
|
| > | > Let Windows regenerate the Swap File
| > | > (Win386.swp) when you boot the copy.
|
|
| > | > | > | > | PCR wrote:
| > | > |
| > | > | > You should investigate why it takes 2/3 boots to boot once,
| > after an
| > | > | > XXCopy. Can it be you copy the swap file (Win386.swp) with
it? I
| > | > have
| > | > | > read that should not be copied. It will generate anew when
you
| > boot
| > | > to
| > | > | > Windows.
| > | > |
| > | > |
| > | > | Perhaps true. I just did it the really dumb and simple way;
Copy
| > and
| > | > Run!
| > | > |
| > | > |
| > | > | Angelo Campanella
| > | > |
| >
| > --
| > Thanks or Good Luck,
| > There may be humor in this post, and,
| > Naturally, you will not sue,
| > should things get worse after this,
| > PCR
| > (e-mail address removed)
| >
| >
|
|
R
Rod Speed
Ah, Kan Yabumoto! This is one bright guy, Yabumoto is.
Reading the URLs you provided, I understand the problem
very likely is & always was solved in the case of XXCopy going
to an empty folder, provided the OS is pure. It is when SFNs
already exist in the destination folder that a problem may arise.
Pity that aint the situation originally being discussed.
The problem with mixed OS's,
That aint the situation being discussed either.
is that they SFNs differently. There are other
cautions mentioned in the URL trail you posted,
but I think it is not involved in this situation.
Yep, and that cant be the reason that a few
reboots are necessary to boot the clone either.
However, there are two versions of XXCopy. The one that
runs in "true" DOS may not be as capable as the 32-bit version.
Waffle. That particular SFN question cant be the cause of
the problem originally being discussed, and neither can the
swap file either. You utterly mangled the story, as I said.
Yet this is likely not the reason cindykapitan
needs to boot thrice to boot once.
Yep, you have finally managed to grasp that NOW. And it wasnt
cindykapitan that had that problem, it was Angelo Campanella.
But I never said it was!
Liar. You initially claimed that the problem could be the
swap file being copied. Wrong. Then you claimed that it
could be xxcopy at fault with that SFN problem. Wrong.
Its all still in the quoting below.
I take you at your word that XXCopy
also handles the Swap File correctly.
You dont have to take my word for that, Kan says that quite explicitly.
I only offered that as a possibility.
Neither of those are a possibility.
So, why does she need to boot thrice?
Most likely some problem with clone
drive or the controller channel its on.
......Start...of exchange between me & him......
Which basically just says in more words that
your original claim that xxcopy could be the
reason for the multiple boots is just plain wrong.
If there is a problem with the SFN/LFN pair,
the problem would occur on every boot attempt.
C
cquirke
Fascinating stuff on LFNs and XXCopy, etc.
FWIW, some background stuff..
http://users.iafrica.com/c/cq/cquirke/lfns.htm on LFNs
http://users.iafrica.com/c/cq/cquirke/dataman.htm/backup_issues on
backup approaches and problems
Can Win9x-LFN-algorithm Win9x read NT-LFN-algorithm LFNs?
For file names, period; the rules often clash. That (plus "why is
everything read-only?") is why I advise against raw file copy to
CDR(W) for all but the most trivial backup purposes. Wrap it in a
..zip, benefit from CRC - but this will leave 8.3 names to be generate
on the fly during restore, and thus LFN-8.3 ambiguity again.
Using XXCopy in one direction doesn't help if you use something else
in the other direction, and some DOS mode LFN tools are buggy.
That suggests XXCopy can't manage LFNs in DOS mode at all ...?
It's always a potential problem, regardless of "mitigating factors"
The big crisis will be...
"C:\Program Files\Microsoft Office"
"C:\Program Files\Microsoft NetMeeting"
"C:\Program Files\Microsoft Windows Media Player"
"C:\Program Files\Microsoft Did We Mention Microsoft Wrote This Yet"
....especially where registry or Path refs using underlying 8.3 abound.
That's just the hem of a very rancid sock.
FWIW, some background stuff..
http://users.iafrica.com/c/cq/cquirke/lfns.htm on LFNs
http://users.iafrica.com/c/cq/cquirke/dataman.htm/backup_issues on
backup approaches and problems
"Kan Yabumoto" <[email protected]> wrote in message
| Hi, PCR;
| XXCOPY's /NX operation (it is a default setting) tries to preserve the
| SFN that is associated with the source file at the destination file
| as much as possible. Since this feature is only an added "bonus"
| when XXCOPY finds a situation in the destination which does not
| easily accommodate the desired outcome, it gives up the effort on
| that file. There are a number of scenarios where the /NX operation
| fails. For example, when there is another file in the destination
| which already has the desired file name, then, XXCOPY will not try
| to vacate the desired SFN by renaming the existing one. Another
| scenario is when the source or destination volume is controlled by
| both Win9X/ME and NT/2K/XP families of Windows (e.g., with a dual-boot
| system). While the first four SFN names are synthesized using the
| same scheme (starting with XXXXXX~1, XXXXXX~2, .... XXXXXX~4) by both
| the 9X/ME family and the NT family, the NT-family Windows switches
| the algorithm using a 4-digit hexadecimal hash value (e.g., XXABCD~1)
| to avoid excessive SFN collisions.
Can Win9x-LFN-algorithm Win9x read NT-LFN-algorithm LFNs?
| Another notable case is with the file system for the CD-R/W
| (packet-write) volume such as InCD and DirectCD. The file system
| for CD-R/W uses a totally different scheme to assign the SFN.
For file names, period; the rules often clash. That (plus "why is
everything read-only?") is why I advise against raw file copy to
CDR(W) for all but the most trivial backup purposes. Wrap it in a
..zip, benefit from CRC - but this will leave 8.3 names to be generate
on the fly during restore, and thus LFN-8.3 ambiguity again.
Using XXCopy in one direction doesn't help if you use something else
in the other direction, and some DOS mode LFN tools are buggy.
| Since XXCOPY uses a combination of standard file I/O API functions
| iteratively to manipulate the SFN in order to preserve the
| SFN (rather than using direct low-level device I/O operations),
| XXCOPY will give up the /NX operation when the SFN preservation is
| not possible.
That suggests XXCopy can't manage LFNs in DOS mode at all ...?
| Therefore, it is true that XXCOPY does not always succeed in
| preserving the SFN. However, we believe it is not critical in
| most situations (except when one tries to save the whole system
| volume into a CD-R/W volume and hopes to maintain the exact
| 8.3-name based referencing --- often found in the system registry).
It's always a potential problem, regardless of "mitigating factors"
| Typically, the most common place to encounter a massive SFN-collisions
| is in the cookies directory where the web browser (e.g., IE and
Mozilla) | saves cookies using a series of files whose name share the
| same beginning. Since the cookie files are always referenced by
| their LFN name, the SFN preservation for those files should not
| be critical.
The big crisis will be...
"C:\Program Files\Microsoft Office"
"C:\Program Files\Microsoft NetMeeting"
"C:\Program Files\Microsoft Windows Media Player"
"C:\Program Files\Microsoft Did We Mention Microsoft Wrote This Yet"
....especially where registry or Path refs using underlying 8.3 abound.
| The most important SFN that should be preserved is the common
| ones such as "C:\Program Files\", "C:\Documents and Settings\".
That's just the hem of a very rancid sock.
Error Messages Are Your Friends--------------- ----- ---- --- -- - - -
P
PCR
Well, you are tough to please, Rod Speed. But I never did come here to
please you.
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
|
| |
| > Ah, Kan Yabumoto! This is one bright guy, Yabumoto is.
|
| > Reading the URLs you provided, I understand the problem
| > very likely is & always was solved in the case of XXCopy going
| > to an empty folder, provided the OS is pure. It is when SFNs
| > already exist in the destination folder that a problem may arise.
|
| Pity that aint the situation originally being discussed.
|
| > The problem with mixed OS's,
|
| That aint the situation being discussed either.
|
| > is that they SFNs differently. There are other
| > cautions mentioned in the URL trail you posted,
| > but I think it is not involved in this situation.
|
| Yep, and that cant be the reason that a few
| reboots are necessary to boot the clone either.
|
| > However, there are two versions of XXCopy. The one that
| > runs in "true" DOS may not be as capable as the 32-bit version.
|
| Waffle. That particular SFN question cant be the cause of
| the problem originally being discussed, and neither can the
| swap file either. You utterly mangled the story, as I said.
|
| > Yet this is likely not the reason cindykapitan
| > needs to boot thrice to boot once.
|
| Yep, you have finally managed to grasp that NOW. And it wasnt
| cindykapitan that had that problem, it was Angelo Campanella.
|
| > But I never said it was!
|
| Liar. You initially claimed that the problem could be the
| swap file being copied. Wrong. Then you claimed that it
| could be xxcopy at fault with that SFN problem. Wrong.
|
| Its all still in the quoting below.
|
| > I take you at your word that XXCopy
| > also handles the Swap File correctly.
|
| You dont have to take my word for that, Kan says that quite
explicitly.
|
| > I only offered that as a possibility.
|
| Neither of those are a possibility.
|
| > So, why does she need to boot thrice?
|
| Most likely some problem with clone
| drive or the controller channel its on.
|
| > ......Start...of exchange between me & him......
|
| Which basically just says in more words that
| your original claim that xxcopy could be the
| reason for the multiple boots is just plain wrong.
|
| If there is a problem with the SFN/LFN pair,
| the problem would occur on every boot attempt.
|
|
| > | > | Hi, PCR;
| > |
| > | XXCOPY's /NX operation (it is a default setting) tries to preserve
the
| > | SFN that is associated with the source file at the destination
file
| > | as much as possible. Since this feature is only an added "bonus"
| > | when XXCOPY finds a situation in the destination which does not
| > | easily accommodate the desired outcome, it gives up the effort on
| > | that file. There are a number of scenarios where the /NX
operation
| > | fails. For example, when there is another file in the destination
| > | which already has the desired file name, then, XXCOPY will not try
| > | to vacate the desired SFN by renaming the existing one. Another
| > | scenario is when the source or destination volume is controlled by
| > | both Win9X/ME and NT/2K/XP families of Windows (e.g., with a
dual-boot
| > | system). While the first four SFN names are synthesized using the
| > | same scheme (starting with XXXXXX~1, XXXXXX~2, .... XXXXXX~4) by
both
| > | the 9X/ME family and the NT family, the NT-family Windows switches
| > | the algorithm using a 4-digit hexadecimal hash value (e.g.,
XXABCD~1)
| > | to avoid excessive SFN collisions. The following article
explains
| > | the details:
| > |
| > | http://www.xxcopy.com/xxcopy08.htm
| > |
| > | Another notable case is with the file system for the CD-R/W
| > | (packet-write) volume such as InCD and DirectCD. The file system
| > | for CD-R/W uses a totally different scheme to assign the SFN.
| > |
| > | Since XXCOPY uses a combination of standard file I/O API functions
| > | iteratively to manipulate the SFN in order to preserve the
| > | SFN (rather than using direct low-level device I/O operations),
| > | XXCOPY will give up the /NX operation when the SFN preservation is
| > | not possible.
| > |
| > | Therefore, it is true that XXCOPY does not always succeed in
| > | preserving the SFN. However, we believe it is not critical in
| > | most situations (except when one tries to save the whole system
| > | volume into a CD-R/W volume and hopes to maintain the exact
| > | 8.3-name based referencing --- often found in the system
registry).
| > | Typically, the most common place to encounter a massive
SFN-collisions
| > | is in the cookies directory where the web browser (e.g., IE and
| > Mozilla)
| > | saves cookies using a series of files whose name share the
| > | same beginning. Since the cookie files are always referenced by
| > | their LFN name, the SFN preservation for those files should not
| > | be critical.
| > |
| > | The most important SFN that should be preserved is the common
| > | ones such as "C:\Program Files\", "C:\Documents and Settings\".
| > |
| > | Kan Yabumoto
| > | The author of XXCopy
| > |
====================================================================
| > | > | > Mr. Yabumoto, I thought I read somewhere that even XXCopy has a
| > problem
| > | > with Short File Names (8+3), after the tilde (~), if two in the
same
| > | > folder differ only by the tilde portion. Is that true?
| > | >
| > | > --
| > | > Thanks & Good Luck,
| > | > PCR
| > | > (e-mail address removed)
| > ......End...of exchange between me & him......
| >
| > --
| > Thanks or Good Luck,
| > There may be humor in this post, and,
| > Naturally, you will not sue,
| > should things get worse after this,
| > PCR
| > (e-mail address removed)
| > | > |
| > | | > |
| > | > | > Well, you must investigate. Let me see whether I have a
site...
| > | > | > http://www.xxcopy.com/
| > | > | > What about the XXCopy site, itself? Surely there are FAQs
there?
| > |
| > | > | > I also know XXCopy suffers of Short File Name mishaps. That
is,
| > | > | > if there are two or more names such as "Progra~1" &
"Progra~2",
| > | > | > there is a possibility they are switched in the copy. They
will
| > get
| > | > | > the correct LFN, but "can" get switched in the SFN. This
would
| > | > | > only matter if something referred to the SFN.
| > |
| > | > | You've mangled that utterly. Its the standard xcopy that has
that
| > | > | particularly problem and xxcopy that ensures that doesnt
happen.
| > |
| > | > No. I did not.
| > |
| > | Yes you did, utterly.
| > |
| > | > Gosh, I can't recall his name, but the author
| > | > of XXCopy said it is a Windows problem.
| > |
| > | And YOU claimed above that its an xxcopy problem which it aint.
| > | He says very explicitly indeed that xxcopy FIXES that problem.
| > | http://www.xxcopy.com/xxcopy03.htm
| > |
| > | > Harper even posted that Explorer itself suffers of it, not just
DOS.
| > |
| > | I didnt even mention dos.
| > |
| > | > It is as I said.
| > |
| > | Nope, not as far as xxcopy having the problem it aint.
| > |
| > | > LFNs will still be assigned to the proper file, but SFNs can
switch.
| > |
| > | Not when xxcopy is used.
| > |
| > | > Sorry, I have no quick way to find the URL Harper posted about
it.
| > |
| > | > But, create say nine files in one folder that will get names
| > "Progra~1"
| > | > through "Progra~9". Then try the copy in DOS & in Explorer.
| > |
| > | Pity about what happens when xxcopy is used. THATS
| > | what you mangled utterly. It FIXES that problem by
| > | ensuring that the short and long file name pairs are
| > | the same on the source and the destination.
| > |
| > | > | > However, I can't see how three re-boots could fix such a
thing.
| > |
| > | > | It cant, and there is nothing to be 'fixed' in that area
anyway.
| > |
| > | > | > But never copy your Swap File that
| > | > | > way. That might have done it, I think.
| > |
| > | > | Unlikely that 3 reboots would fix that either.
| > |
| > | > It isn't an experiment I will do. However, Angelo might, when
| > | > next he does his XXCopy. (He's already done it the wrong way.)
| > | > Copying the Swap File that way is the most often heard
| > | > prohibition about Xcopy32, XXCopy & even an Explorer copy.
| > |
| > | Thats for a different reason. Win just wont let you copy the
| > | swap file and so the copy aborts when you get to that file.
| > |
| > | And the xxcopy documentation doesnt say its a problem.
| > | http://www.xxcopy.com/xxcopy10.htm
| > |
| > | In fact it wont copy it and that will cause an automatic
| > | recreation of that file when the clone is booted.
| > |
| > | > | > Let Windows regenerate the Swap File
| > | > | > (Win386.swp) when you boot the copy.
| > |
| > |
| > | > | > | > | > | > | PCR wrote:
| > | > | > |
| > | > | > | > You should investigate why it takes 2/3 boots to boot
once,
| > | > after an
| > | > | > | > XXCopy. Can it be you copy the swap file (Win386.swp)
with
| > it? I
| > | > | > have
| > | > | > | > read that should not be copied. It will generate anew
when
| > you
| > | > boot
| > | > | > to
| > | > | > | > Windows.
| > | > | > |
| > | > | > |
| > | > | > | Perhaps true. I just did it the really dumb and simple
way;
| > Copy
| > | > and
| > | > | > Run!
| > | > | > |
| > | > | > |
| > | > | > | Angelo Campanella
| > | > | > |
| > | >
| > | > --
| > | > Thanks or Good Luck,
| > | > There may be humor in this post, and,
| > | > Naturally, you will not sue,
| > | > should things get worse after this,
| > | > PCR
| > | > (e-mail address removed)
| > | >
| > | >
| > |
| > |
| >
| >
|
|
please you.
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
|
| |
| > Ah, Kan Yabumoto! This is one bright guy, Yabumoto is.
|
| > Reading the URLs you provided, I understand the problem
| > very likely is & always was solved in the case of XXCopy going
| > to an empty folder, provided the OS is pure. It is when SFNs
| > already exist in the destination folder that a problem may arise.
|
| Pity that aint the situation originally being discussed.
|
| > The problem with mixed OS's,
|
| That aint the situation being discussed either.
|
| > is that they SFNs differently. There are other
| > cautions mentioned in the URL trail you posted,
| > but I think it is not involved in this situation.
|
| Yep, and that cant be the reason that a few
| reboots are necessary to boot the clone either.
|
| > However, there are two versions of XXCopy. The one that
| > runs in "true" DOS may not be as capable as the 32-bit version.
|
| Waffle. That particular SFN question cant be the cause of
| the problem originally being discussed, and neither can the
| swap file either. You utterly mangled the story, as I said.
|
| > Yet this is likely not the reason cindykapitan
| > needs to boot thrice to boot once.
|
| Yep, you have finally managed to grasp that NOW. And it wasnt
| cindykapitan that had that problem, it was Angelo Campanella.
|
| > But I never said it was!
|
| Liar. You initially claimed that the problem could be the
| swap file being copied. Wrong. Then you claimed that it
| could be xxcopy at fault with that SFN problem. Wrong.
|
| Its all still in the quoting below.
|
| > I take you at your word that XXCopy
| > also handles the Swap File correctly.
|
| You dont have to take my word for that, Kan says that quite
explicitly.
|
| > I only offered that as a possibility.
|
| Neither of those are a possibility.
|
| > So, why does she need to boot thrice?
|
| Most likely some problem with clone
| drive or the controller channel its on.
|
| > ......Start...of exchange between me & him......
|
| Which basically just says in more words that
| your original claim that xxcopy could be the
| reason for the multiple boots is just plain wrong.
|
| If there is a problem with the SFN/LFN pair,
| the problem would occur on every boot attempt.
|
|
| > | > | Hi, PCR;
| > |
| > | XXCOPY's /NX operation (it is a default setting) tries to preserve
the
| > | SFN that is associated with the source file at the destination
file
| > | as much as possible. Since this feature is only an added "bonus"
| > | when XXCOPY finds a situation in the destination which does not
| > | easily accommodate the desired outcome, it gives up the effort on
| > | that file. There are a number of scenarios where the /NX
operation
| > | fails. For example, when there is another file in the destination
| > | which already has the desired file name, then, XXCOPY will not try
| > | to vacate the desired SFN by renaming the existing one. Another
| > | scenario is when the source or destination volume is controlled by
| > | both Win9X/ME and NT/2K/XP families of Windows (e.g., with a
dual-boot
| > | system). While the first four SFN names are synthesized using the
| > | same scheme (starting with XXXXXX~1, XXXXXX~2, .... XXXXXX~4) by
both
| > | the 9X/ME family and the NT family, the NT-family Windows switches
| > | the algorithm using a 4-digit hexadecimal hash value (e.g.,
XXABCD~1)
| > | to avoid excessive SFN collisions. The following article
explains
| > | the details:
| > |
| > | http://www.xxcopy.com/xxcopy08.htm
| > |
| > | Another notable case is with the file system for the CD-R/W
| > | (packet-write) volume such as InCD and DirectCD. The file system
| > | for CD-R/W uses a totally different scheme to assign the SFN.
| > |
| > | Since XXCOPY uses a combination of standard file I/O API functions
| > | iteratively to manipulate the SFN in order to preserve the
| > | SFN (rather than using direct low-level device I/O operations),
| > | XXCOPY will give up the /NX operation when the SFN preservation is
| > | not possible.
| > |
| > | Therefore, it is true that XXCOPY does not always succeed in
| > | preserving the SFN. However, we believe it is not critical in
| > | most situations (except when one tries to save the whole system
| > | volume into a CD-R/W volume and hopes to maintain the exact
| > | 8.3-name based referencing --- often found in the system
registry).
| > | Typically, the most common place to encounter a massive
SFN-collisions
| > | is in the cookies directory where the web browser (e.g., IE and
| > Mozilla)
| > | saves cookies using a series of files whose name share the
| > | same beginning. Since the cookie files are always referenced by
| > | their LFN name, the SFN preservation for those files should not
| > | be critical.
| > |
| > | The most important SFN that should be preserved is the common
| > | ones such as "C:\Program Files\", "C:\Documents and Settings\".
| > |
| > | Kan Yabumoto
| > | The author of XXCopy
| > |
====================================================================
| > | > | > Mr. Yabumoto, I thought I read somewhere that even XXCopy has a
| > problem
| > | > with Short File Names (8+3), after the tilde (~), if two in the
same
| > | > folder differ only by the tilde portion. Is that true?
| > | >
| > | > --
| > | > Thanks & Good Luck,
| > | > PCR
| > | > (e-mail address removed)
| > ......End...of exchange between me & him......
| >
| > --
| > Thanks or Good Luck,
| > There may be humor in this post, and,
| > Naturally, you will not sue,
| > should things get worse after this,
| > PCR
| > (e-mail address removed)
| > | > |
| > | | > |
| > | > | > Well, you must investigate. Let me see whether I have a
site...
| > | > | > http://www.xxcopy.com/
| > | > | > What about the XXCopy site, itself? Surely there are FAQs
there?
| > |
| > | > | > I also know XXCopy suffers of Short File Name mishaps. That
is,
| > | > | > if there are two or more names such as "Progra~1" &
"Progra~2",
| > | > | > there is a possibility they are switched in the copy. They
will
| > get
| > | > | > the correct LFN, but "can" get switched in the SFN. This
would
| > | > | > only matter if something referred to the SFN.
| > |
| > | > | You've mangled that utterly. Its the standard xcopy that has
that
| > | > | particularly problem and xxcopy that ensures that doesnt
happen.
| > |
| > | > No. I did not.
| > |
| > | Yes you did, utterly.
| > |
| > | > Gosh, I can't recall his name, but the author
| > | > of XXCopy said it is a Windows problem.
| > |
| > | And YOU claimed above that its an xxcopy problem which it aint.
| > | He says very explicitly indeed that xxcopy FIXES that problem.
| > | http://www.xxcopy.com/xxcopy03.htm
| > |
| > | > Harper even posted that Explorer itself suffers of it, not just
DOS.
| > |
| > | I didnt even mention dos.
| > |
| > | > It is as I said.
| > |
| > | Nope, not as far as xxcopy having the problem it aint.
| > |
| > | > LFNs will still be assigned to the proper file, but SFNs can
switch.
| > |
| > | Not when xxcopy is used.
| > |
| > | > Sorry, I have no quick way to find the URL Harper posted about
it.
| > |
| > | > But, create say nine files in one folder that will get names
| > "Progra~1"
| > | > through "Progra~9". Then try the copy in DOS & in Explorer.
| > |
| > | Pity about what happens when xxcopy is used. THATS
| > | what you mangled utterly. It FIXES that problem by
| > | ensuring that the short and long file name pairs are
| > | the same on the source and the destination.
| > |
| > | > | > However, I can't see how three re-boots could fix such a
thing.
| > |
| > | > | It cant, and there is nothing to be 'fixed' in that area
anyway.
| > |
| > | > | > But never copy your Swap File that
| > | > | > way. That might have done it, I think.
| > |
| > | > | Unlikely that 3 reboots would fix that either.
| > |
| > | > It isn't an experiment I will do. However, Angelo might, when
| > | > next he does his XXCopy. (He's already done it the wrong way.)
| > | > Copying the Swap File that way is the most often heard
| > | > prohibition about Xcopy32, XXCopy & even an Explorer copy.
| > |
| > | Thats for a different reason. Win just wont let you copy the
| > | swap file and so the copy aborts when you get to that file.
| > |
| > | And the xxcopy documentation doesnt say its a problem.
| > | http://www.xxcopy.com/xxcopy10.htm
| > |
| > | In fact it wont copy it and that will cause an automatic
| > | recreation of that file when the clone is booted.
| > |
| > | > | > Let Windows regenerate the Swap File
| > | > | > (Win386.swp) when you boot the copy.
| > |
| > |
| > | > | > | > | > | > | PCR wrote:
| > | > | > |
| > | > | > | > You should investigate why it takes 2/3 boots to boot
once,
| > | > after an
| > | > | > | > XXCopy. Can it be you copy the swap file (Win386.swp)
with
| > it? I
| > | > | > have
| > | > | > | > read that should not be copied. It will generate anew
when
| > you
| > | > boot
| > | > | > to
| > | > | > | > Windows.
| > | > | > |
| > | > | > |
| > | > | > | Perhaps true. I just did it the really dumb and simple
way;
| > Copy
| > | > and
| > | > | > Run!
| > | > | > |
| > | > | > |
| > | > | > | Angelo Campanella
| > | > | > |
| > | >
| > | > --
| > | > Thanks or Good Luck,
| > | > There may be humor in this post, and,
| > | > Naturally, you will not sue,
| > | > should things get worse after this,
| > | > PCR
| > | > (e-mail address removed)
| > | >
| > | >
| > |
| > |
| >
| >
|
|
P
PCR
Really, I came to play baseball with Campanella.
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
|
| |
| > Well, you are tough to please, Rod Speed.
|
| Wrong. As always.
|
| > But I never did come here to please you.
|
| Wrong. As always.
|
|
| > | > |
| > | | > |
| > | > Ah, Kan Yabumoto! This is one bright guy, Yabumoto is.
| > |
| > | > Reading the URLs you provided, I understand the problem
| > | > very likely is & always was solved in the case of XXCopy going
| > | > to an empty folder, provided the OS is pure. It is when SFNs
| > | > already exist in the destination folder that a problem may
arise.
| > |
| > | Pity that aint the situation originally being discussed.
| > |
| > | > The problem with mixed OS's,
| > |
| > | That aint the situation being discussed either.
| > |
| > | > is that they SFNs differently. There are other
| > | > cautions mentioned in the URL trail you posted,
| > | > but I think it is not involved in this situation.
| > |
| > | Yep, and that cant be the reason that a few
| > | reboots are necessary to boot the clone either.
| > |
| > | > However, there are two versions of XXCopy. The one that
| > | > runs in "true" DOS may not be as capable as the 32-bit version.
| > |
| > | Waffle. That particular SFN question cant be the cause of
| > | the problem originally being discussed, and neither can the
| > | swap file either. You utterly mangled the story, as I said.
| > |
| > | > Yet this is likely not the reason cindykapitan
| > | > needs to boot thrice to boot once.
| > |
| > | Yep, you have finally managed to grasp that NOW. And it wasnt
| > | cindykapitan that had that problem, it was Angelo Campanella.
| > |
| > | > But I never said it was!
| > |
| > | Liar. You initially claimed that the problem could be the
| > | swap file being copied. Wrong. Then you claimed that it
| > | could be xxcopy at fault with that SFN problem. Wrong.
| > |
| > | Its all still in the quoting below.
| > |
| > | > I take you at your word that XXCopy
| > | > also handles the Swap File correctly.
| > |
| > | You dont have to take my word for that, Kan says that quite
| > explicitly.
| > |
| > | > I only offered that as a possibility.
| > |
| > | Neither of those are a possibility.
| > |
| > | > So, why does she need to boot thrice?
| > |
| > | Most likely some problem with clone
| > | drive or the controller channel its on.
| > |
| > | > ......Start...of exchange between me & him......
| > |
| > | Which basically just says in more words that
| > | your original claim that xxcopy could be the
| > | reason for the multiple boots is just plain wrong.
| > |
| > | If there is a problem with the SFN/LFN pair,
| > | the problem would occur on every boot attempt.
| > |
| > |
| > | > | > | > | Hi, PCR;
| > | > |
| > | > | XXCOPY's /NX operation (it is a default setting) tries to
preserve
| > the
| > | > | SFN that is associated with the source file at the destination
| > file
| > | > | as much as possible. Since this feature is only an added
"bonus"
| > | > | when XXCOPY finds a situation in the destination which does
not
| > | > | easily accommodate the desired outcome, it gives up the effort
on
| > | > | that file. There are a number of scenarios where the /NX
| > operation
| > | > | fails. For example, when there is another file in the
destination
| > | > | which already has the desired file name, then, XXCOPY will not
try
| > | > | to vacate the desired SFN by renaming the existing one.
Another
| > | > | scenario is when the source or destination volume is
controlled by
| > | > | both Win9X/ME and NT/2K/XP families of Windows (e.g., with a
| > dual-boot
| > | > | system). While the first four SFN names are synthesized using
the
| > | > | same scheme (starting with XXXXXX~1, XXXXXX~2, .... XXXXXX~4)
by
| > both
| > | > | the 9X/ME family and the NT family, the NT-family Windows
switches
| > | > | the algorithm using a 4-digit hexadecimal hash value (e.g.,
| > XXABCD~1)
| > | > | to avoid excessive SFN collisions. The following article
| > explains
| > | > | the details:
| > | > |
| > | > | http://www.xxcopy.com/xxcopy08.htm
| > | > |
| > | > | Another notable case is with the file system for the CD-R/W
| > | > | (packet-write) volume such as InCD and DirectCD. The file
system
| > | > | for CD-R/W uses a totally different scheme to assign the SFN.
| > | > |
| > | > | Since XXCOPY uses a combination of standard file I/O API
functions
| > | > | iteratively to manipulate the SFN in order to preserve the
| > | > | SFN (rather than using direct low-level device I/O
operations),
| > | > | XXCOPY will give up the /NX operation when the SFN
preservation is
| > | > | not possible.
| > | > |
| > | > | Therefore, it is true that XXCOPY does not always succeed in
| > | > | preserving the SFN. However, we believe it is not critical in
| > | > | most situations (except when one tries to save the whole
system
| > | > | volume into a CD-R/W volume and hopes to maintain the exact
| > | > | 8.3-name based referencing --- often found in the system
| > registry).
| > | > | Typically, the most common place to encounter a massive
| > SFN-collisions
| > | > | is in the cookies directory where the web browser (e.g., IE
and
| > | > Mozilla)
| > | > | saves cookies using a series of files whose name share the
| > | > | same beginning. Since the cookie files are always referenced
by
| > | > | their LFN name, the SFN preservation for those files should
not
| > | > | be critical.
| > | > |
| > | > | The most important SFN that should be preserved is the common
| > | > | ones such as "C:\Program Files\", "C:\Documents and
Settings\".
| > | > |
| > | > | Kan Yabumoto
| > | > | The author of XXCopy
| > | > |
| > ====================================================================
| > | > | > | > | > Mr. Yabumoto, I thought I read somewhere that even XXCopy
has a
| > | > problem
| > | > | > with Short File Names (8+3), after the tilde (~), if two in
the
| > same
| > | > | > folder differ only by the tilde portion. Is that true?
| > | > | >
| > | > | > --
| > | > | > Thanks & Good Luck,
| > | > | > PCR
| > | > | > (e-mail address removed)
| > | > ......End...of exchange between me & him......
| > | >
| > | > --
| > | > Thanks or Good Luck,
| > | > There may be humor in this post, and,
| > | > Naturally, you will not sue,
| > | > should things get worse after this,
| > | > PCR
| > | > (e-mail address removed)
| > | > | > | > |
| > | > | | > | > |
| > | > | > | > Well, you must investigate. Let me see whether I have a
| > site...
| > | > | > | > http://www.xxcopy.com/
| > | > | > | > What about the XXCopy site, itself? Surely there are
FAQs
| > there?
| > | > |
| > | > | > | > I also know XXCopy suffers of Short File Name mishaps.
That
| > is,
| > | > | > | > if there are two or more names such as "Progra~1" &
| > "Progra~2",
| > | > | > | > there is a possibility they are switched in the copy.
They
| > will
| > | > get
| > | > | > | > the correct LFN, but "can" get switched in the SFN. This
| > would
| > | > | > | > only matter if something referred to the SFN.
| > | > |
| > | > | > | You've mangled that utterly. Its the standard xcopy that
has
| > that
| > | > | > | particularly problem and xxcopy that ensures that doesnt
| > happen.
| > | > |
| > | > | > No. I did not.
| > | > |
| > | > | Yes you did, utterly.
| > | > |
| > | > | > Gosh, I can't recall his name, but the author
| > | > | > of XXCopy said it is a Windows problem.
| > | > |
| > | > | And YOU claimed above that its an xxcopy problem which it
aint.
| > | > | He says very explicitly indeed that xxcopy FIXES that problem.
| > | > | http://www.xxcopy.com/xxcopy03.htm
| > | > |
| > | > | > Harper even posted that Explorer itself suffers of it, not
just
| > DOS.
| > | > |
| > | > | I didnt even mention dos.
| > | > |
| > | > | > It is as I said.
| > | > |
| > | > | Nope, not as far as xxcopy having the problem it aint.
| > | > |
| > | > | > LFNs will still be assigned to the proper file, but SFNs can
| > switch.
| > | > |
| > | > | Not when xxcopy is used.
| > | > |
| > | > | > Sorry, I have no quick way to find the URL Harper posted
about
| > it.
| > | > |
| > | > | > But, create say nine files in one folder that will get names
| > | > "Progra~1"
| > | > | > through "Progra~9". Then try the copy in DOS & in Explorer.
| > | > |
| > | > | Pity about what happens when xxcopy is used. THATS
| > | > | what you mangled utterly. It FIXES that problem by
| > | > | ensuring that the short and long file name pairs are
| > | > | the same on the source and the destination.
| > | > |
| > | > | > | > However, I can't see how three re-boots could fix such a
| > thing.
| > | > |
| > | > | > | It cant, and there is nothing to be 'fixed' in that area
| > anyway.
| > | > |
| > | > | > | > But never copy your Swap File that
| > | > | > | > way. That might have done it, I think.
| > | > |
| > | > | > | Unlikely that 3 reboots would fix that either.
| > | > |
| > | > | > It isn't an experiment I will do. However, Angelo might,
when
| > | > | > next he does his XXCopy. (He's already done it the wrong
way.)
| > | > | > Copying the Swap File that way is the most often heard
| > | > | > prohibition about Xcopy32, XXCopy & even an Explorer copy.
| > | > |
| > | > | Thats for a different reason. Win just wont let you copy the
| > | > | swap file and so the copy aborts when you get to that file.
| > | > |
| > | > | And the xxcopy documentation doesnt say its a problem.
| > | > | http://www.xxcopy.com/xxcopy10.htm
| > | > |
| > | > | In fact it wont copy it and that will cause an automatic
| > | > | recreation of that file when the clone is booted.
| > | > |
| > | > | > | > Let Windows regenerate the Swap File
| > | > | > | > (Win386.swp) when you boot the copy.
| > | > |
| > | > |
message
| > | > | > | > | > | > | > | > | PCR wrote:
| > | > | > | > |
| > | > | > | > | > You should investigate why it takes 2/3 boots to
boot
| > once,
| > | > | > after an
| > | > | > | > | > XXCopy. Can it be you copy the swap file
(Win386.swp)
| > with
| > | > it? I
| > | > | > | > have
| > | > | > | > | > read that should not be copied. It will generate
anew
| > when
| > | > you
| > | > | > boot
| > | > | > | > to
| > | > | > | > | > Windows.
| > | > | > | > |
| > | > | > | > |
| > | > | > | > | Perhaps true. I just did it the really dumb and simple
| > way;
| > | > Copy
| > | > | > and
| > | > | > | > Run!
| > | > | > | > |
| > | > | > | > |
| > | > | > | > | Angelo Campanella
| > | > | > | > |
| > | > | >
| > | > | > --
| > | > | > Thanks or Good Luck,
| > | > | > There may be humor in this post, and,
| > | > | > Naturally, you will not sue,
| > | > | > should things get worse after this,
| > | > | > PCR
| > | > | > (e-mail address removed)
| > | > | >
| > | > | >
| > | > |
| > | > |
| > | >
| > | >
| > |
| > |
| >
| >
|
|
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
|
| |
| > Well, you are tough to please, Rod Speed.
|
| Wrong. As always.
|
| > But I never did come here to please you.
|
| Wrong. As always.
|
|
| > | > |
| > | | > |
| > | > Ah, Kan Yabumoto! This is one bright guy, Yabumoto is.
| > |
| > | > Reading the URLs you provided, I understand the problem
| > | > very likely is & always was solved in the case of XXCopy going
| > | > to an empty folder, provided the OS is pure. It is when SFNs
| > | > already exist in the destination folder that a problem may
arise.
| > |
| > | Pity that aint the situation originally being discussed.
| > |
| > | > The problem with mixed OS's,
| > |
| > | That aint the situation being discussed either.
| > |
| > | > is that they SFNs differently. There are other
| > | > cautions mentioned in the URL trail you posted,
| > | > but I think it is not involved in this situation.
| > |
| > | Yep, and that cant be the reason that a few
| > | reboots are necessary to boot the clone either.
| > |
| > | > However, there are two versions of XXCopy. The one that
| > | > runs in "true" DOS may not be as capable as the 32-bit version.
| > |
| > | Waffle. That particular SFN question cant be the cause of
| > | the problem originally being discussed, and neither can the
| > | swap file either. You utterly mangled the story, as I said.
| > |
| > | > Yet this is likely not the reason cindykapitan
| > | > needs to boot thrice to boot once.
| > |
| > | Yep, you have finally managed to grasp that NOW. And it wasnt
| > | cindykapitan that had that problem, it was Angelo Campanella.
| > |
| > | > But I never said it was!
| > |
| > | Liar. You initially claimed that the problem could be the
| > | swap file being copied. Wrong. Then you claimed that it
| > | could be xxcopy at fault with that SFN problem. Wrong.
| > |
| > | Its all still in the quoting below.
| > |
| > | > I take you at your word that XXCopy
| > | > also handles the Swap File correctly.
| > |
| > | You dont have to take my word for that, Kan says that quite
| > explicitly.
| > |
| > | > I only offered that as a possibility.
| > |
| > | Neither of those are a possibility.
| > |
| > | > So, why does she need to boot thrice?
| > |
| > | Most likely some problem with clone
| > | drive or the controller channel its on.
| > |
| > | > ......Start...of exchange between me & him......
| > |
| > | Which basically just says in more words that
| > | your original claim that xxcopy could be the
| > | reason for the multiple boots is just plain wrong.
| > |
| > | If there is a problem with the SFN/LFN pair,
| > | the problem would occur on every boot attempt.
| > |
| > |
| > | > | > | > | Hi, PCR;
| > | > |
| > | > | XXCOPY's /NX operation (it is a default setting) tries to
preserve
| > the
| > | > | SFN that is associated with the source file at the destination
| > file
| > | > | as much as possible. Since this feature is only an added
"bonus"
| > | > | when XXCOPY finds a situation in the destination which does
not
| > | > | easily accommodate the desired outcome, it gives up the effort
on
| > | > | that file. There are a number of scenarios where the /NX
| > operation
| > | > | fails. For example, when there is another file in the
destination
| > | > | which already has the desired file name, then, XXCOPY will not
try
| > | > | to vacate the desired SFN by renaming the existing one.
Another
| > | > | scenario is when the source or destination volume is
controlled by
| > | > | both Win9X/ME and NT/2K/XP families of Windows (e.g., with a
| > dual-boot
| > | > | system). While the first four SFN names are synthesized using
the
| > | > | same scheme (starting with XXXXXX~1, XXXXXX~2, .... XXXXXX~4)
by
| > both
| > | > | the 9X/ME family and the NT family, the NT-family Windows
switches
| > | > | the algorithm using a 4-digit hexadecimal hash value (e.g.,
| > XXABCD~1)
| > | > | to avoid excessive SFN collisions. The following article
| > explains
| > | > | the details:
| > | > |
| > | > | http://www.xxcopy.com/xxcopy08.htm
| > | > |
| > | > | Another notable case is with the file system for the CD-R/W
| > | > | (packet-write) volume such as InCD and DirectCD. The file
system
| > | > | for CD-R/W uses a totally different scheme to assign the SFN.
| > | > |
| > | > | Since XXCOPY uses a combination of standard file I/O API
functions
| > | > | iteratively to manipulate the SFN in order to preserve the
| > | > | SFN (rather than using direct low-level device I/O
operations),
| > | > | XXCOPY will give up the /NX operation when the SFN
preservation is
| > | > | not possible.
| > | > |
| > | > | Therefore, it is true that XXCOPY does not always succeed in
| > | > | preserving the SFN. However, we believe it is not critical in
| > | > | most situations (except when one tries to save the whole
system
| > | > | volume into a CD-R/W volume and hopes to maintain the exact
| > | > | 8.3-name based referencing --- often found in the system
| > registry).
| > | > | Typically, the most common place to encounter a massive
| > SFN-collisions
| > | > | is in the cookies directory where the web browser (e.g., IE
and
| > | > Mozilla)
| > | > | saves cookies using a series of files whose name share the
| > | > | same beginning. Since the cookie files are always referenced
by
| > | > | their LFN name, the SFN preservation for those files should
not
| > | > | be critical.
| > | > |
| > | > | The most important SFN that should be preserved is the common
| > | > | ones such as "C:\Program Files\", "C:\Documents and
Settings\".
| > | > |
| > | > | Kan Yabumoto
| > | > | The author of XXCopy
| > | > |
| > ====================================================================
| > | > | > | > | > Mr. Yabumoto, I thought I read somewhere that even XXCopy
has a
| > | > problem
| > | > | > with Short File Names (8+3), after the tilde (~), if two in
the
| > same
| > | > | > folder differ only by the tilde portion. Is that true?
| > | > | >
| > | > | > --
| > | > | > Thanks & Good Luck,
| > | > | > PCR
| > | > | > (e-mail address removed)
| > | > ......End...of exchange between me & him......
| > | >
| > | > --
| > | > Thanks or Good Luck,
| > | > There may be humor in this post, and,
| > | > Naturally, you will not sue,
| > | > should things get worse after this,
| > | > PCR
| > | > (e-mail address removed)
| > | > | > | > |
| > | > | | > | > |
| > | > | > | > Well, you must investigate. Let me see whether I have a
| > site...
| > | > | > | > http://www.xxcopy.com/
| > | > | > | > What about the XXCopy site, itself? Surely there are
FAQs
| > there?
| > | > |
| > | > | > | > I also know XXCopy suffers of Short File Name mishaps.
That
| > is,
| > | > | > | > if there are two or more names such as "Progra~1" &
| > "Progra~2",
| > | > | > | > there is a possibility they are switched in the copy.
They
| > will
| > | > get
| > | > | > | > the correct LFN, but "can" get switched in the SFN. This
| > would
| > | > | > | > only matter if something referred to the SFN.
| > | > |
| > | > | > | You've mangled that utterly. Its the standard xcopy that
has
| > that
| > | > | > | particularly problem and xxcopy that ensures that doesnt
| > happen.
| > | > |
| > | > | > No. I did not.
| > | > |
| > | > | Yes you did, utterly.
| > | > |
| > | > | > Gosh, I can't recall his name, but the author
| > | > | > of XXCopy said it is a Windows problem.
| > | > |
| > | > | And YOU claimed above that its an xxcopy problem which it
aint.
| > | > | He says very explicitly indeed that xxcopy FIXES that problem.
| > | > | http://www.xxcopy.com/xxcopy03.htm
| > | > |
| > | > | > Harper even posted that Explorer itself suffers of it, not
just
| > DOS.
| > | > |
| > | > | I didnt even mention dos.
| > | > |
| > | > | > It is as I said.
| > | > |
| > | > | Nope, not as far as xxcopy having the problem it aint.
| > | > |
| > | > | > LFNs will still be assigned to the proper file, but SFNs can
| > switch.
| > | > |
| > | > | Not when xxcopy is used.
| > | > |
| > | > | > Sorry, I have no quick way to find the URL Harper posted
about
| > it.
| > | > |
| > | > | > But, create say nine files in one folder that will get names
| > | > "Progra~1"
| > | > | > through "Progra~9". Then try the copy in DOS & in Explorer.
| > | > |
| > | > | Pity about what happens when xxcopy is used. THATS
| > | > | what you mangled utterly. It FIXES that problem by
| > | > | ensuring that the short and long file name pairs are
| > | > | the same on the source and the destination.
| > | > |
| > | > | > | > However, I can't see how three re-boots could fix such a
| > thing.
| > | > |
| > | > | > | It cant, and there is nothing to be 'fixed' in that area
| > anyway.
| > | > |
| > | > | > | > But never copy your Swap File that
| > | > | > | > way. That might have done it, I think.
| > | > |
| > | > | > | Unlikely that 3 reboots would fix that either.
| > | > |
| > | > | > It isn't an experiment I will do. However, Angelo might,
when
| > | > | > next he does his XXCopy. (He's already done it the wrong
way.)
| > | > | > Copying the Swap File that way is the most often heard
| > | > | > prohibition about Xcopy32, XXCopy & even an Explorer copy.
| > | > |
| > | > | Thats for a different reason. Win just wont let you copy the
| > | > | swap file and so the copy aborts when you get to that file.
| > | > |
| > | > | And the xxcopy documentation doesnt say its a problem.
| > | > | http://www.xxcopy.com/xxcopy10.htm
| > | > |
| > | > | In fact it wont copy it and that will cause an automatic
| > | > | recreation of that file when the clone is booted.
| > | > |
| > | > | > | > Let Windows regenerate the Swap File
| > | > | > | > (Win386.swp) when you boot the copy.
| > | > |
| > | > |
message
| > | > | > | > | > | > | > | > | PCR wrote:
| > | > | > | > |
| > | > | > | > | > You should investigate why it takes 2/3 boots to
boot
| > once,
| > | > | > after an
| > | > | > | > | > XXCopy. Can it be you copy the swap file
(Win386.swp)
| > with
| > | > it? I
| > | > | > | > have
| > | > | > | > | > read that should not be copied. It will generate
anew
| > when
| > | > you
| > | > | > boot
| > | > | > | > to
| > | > | > | > | > Windows.
| > | > | > | > |
| > | > | > | > |
| > | > | > | > | Perhaps true. I just did it the really dumb and simple
| > way;
| > | > Copy
| > | > | > and
| > | > | > | > Run!
| > | > | > | > |
| > | > | > | > |
| > | > | > | > | Angelo Campanella
| > | > | > | > |
| > | > | >
| > | > | > --
| > | > | > Thanks or Good Luck,
| > | > | > There may be humor in this post, and,
| > | > | > Naturally, you will not sue,
| > | > | > should things get worse after this,
| > | > | > PCR
| > | > | > (e-mail address removed)
| > | > | >
| > | > | >
| > | > |
| > | > |
| > | >
| > | >
| > |
| > |
| >
| >
|
|
A
Angelo Campanella
Angelo said:I have solved that problem by having a second hard drive that can be
connected as a storage medium. I then use XXCOPY to make a clone of my
existing hard drive. The spare drive must have a capacity same or larger
than the space you are occupying as the regular hard drive. After
copying the cloned version back onto the hard drive (or another you want
to use as the main drive), Windows 98 can be self- booted from that
after about two or three trys at same. W98 seems to "heal" or "grow"
itself to work OK that way!
Allow me to follow-up this article subsequent to various comments on same.
1-
True, my boot tries were muddled by the existing swap file, I suspect. And true,
one can delete it to give the old windows system a new try at same, so there is
no confusion there.
2-
All my long file names remain intact (plain W98). So there is reason for concern
there at all. As a matter of fact, the only time I see short file names now is
because I am still a DOS freak, and I have oodles of DOS apps on my desktop as
icons. And I love to do my directories-dancing in DOS (where short file names
are often displayed) since I know my way around them.
3-
The XXCOPY method has been a real life-saver. It does, however require that your
hardware include a multiple disk connection.
Angelo Campanella
P
PCR
|
| Fascinating stuff on LFNs and XXCopy, etc.
|
| FWIW, some background stuff..
|
| http://users.iafrica.com/c/cq/cquirke/lfns.htm on LFNs
Cquirke, why can't I see that offline? It should be in my TIFs! (Other
stuff I viewed last night does work fine.)
|
| http://users.iafrica.com/c/cq/cquirke/dataman.htm/backup_issues on
| backup approaches and problems
|
|
| >| Hi, PCR;
|
| >| XXCOPY's /NX operation (it is a default setting) tries to preserve
the
| >| SFN that is associated with the source file at the destination file
| >| as much as possible. Since this feature is only an added "bonus"
| >| when XXCOPY finds a situation in the destination which does not
| >| easily accommodate the desired outcome, it gives up the effort on
| >| that file. There are a number of scenarios where the /NX operation
| >| fails. For example, when there is another file in the destination
| >| which already has the desired file name, then, XXCOPY will not try
| >| to vacate the desired SFN by renaming the existing one. Another
| >| scenario is when the source or destination volume is controlled by
| >| both Win9X/ME and NT/2K/XP families of Windows (e.g., with a
dual-boot
| >| system). While the first four SFN names are synthesized using the
| >| same scheme (starting with XXXXXX~1, XXXXXX~2, .... XXXXXX~4) by
both
| >| the 9X/ME family and the NT family, the NT-family Windows switches
| >| the algorithm using a 4-digit hexadecimal hash value (e.g.,
XXABCD~1)
| >| to avoid excessive SFN collisions.
|
| Can Win9x-LFN-algorithm Win9x read NT-LFN-algorithm LFNs?
I think he is saying the differences in the methods makes it impossible
for XXCopy to get it right 100% time in the circumstance of a mixed OS.
XXCopy will err on the side of safety & let the OS generate it's own SFN
in that circumstance. Can Win9x read WinNT? That is a different
question.
However, the implication is that they can coexist on the same OS. Or is
it? Can Yabumoto be talking about copying files to a folder that already
has files in it? Then, the folder had WinNT files but XXCopy is now
asked to put Win9x files into it. Can that be it?
|
| >| http://www.xxcopy.com/xxcopy08.htm
|
| <sigh> ...so many links, so little time...
|
| >| Another notable case is with the file system for the CD-R/W
| >| (packet-write) volume such as InCD and DirectCD. The file system
| >| for CD-R/W uses a totally different scheme to assign the SFN.
|
| For file names, period; the rules often clash. That (plus "why is
| everything read-only?") is why I advise against raw file copy to
| CDR(W) for all but the most trivial backup purposes. Wrap it in a
| .zip, benefit from CRC - but this will leave 8.3 names to be generate
| on the fly during restore, and thus LFN-8.3 ambiguity again.
|
| Using XXCopy in one direction doesn't help if you use something else
| in the other direction, and some DOS mode LFN tools are buggy.
I suppose Yabumoto purposefully did not write his own file system, but
only created a cache to trap SFNs for manipulation. Then, he would read
the destination to see what is there & try to arrange it so those to be
added would end up right (same SFN). Naturally, there were impossible
situations, such as the SFN was already there from a prior copy. Also,
XXCopy must be the one doing the copy for a greater chance to preserve
SFNs. But he didn't leave it so only XXCopy could be used. to make a
copy.
|
| >| Since XXCOPY uses a combination of standard file I/O API functions
| >| iteratively to manipulate the SFN in order to preserve the
| >| SFN (rather than using direct low-level device I/O operations),
| >| XXCOPY will give up the /NX operation when the SFN preservation is
| >| not possible.
|
| That suggests XXCopy can't manage LFNs in DOS mode at all ...?
There are two version of XXCopy. The "true" DOS version is not as
capable.
|
| >| Therefore, it is true that XXCOPY does not always succeed in
| >| preserving the SFN. However, we believe it is not critical in
| >| most situations (except when one tries to save the whole system
| >| volume into a CD-R/W volume and hopes to maintain the exact
| >| 8.3-name based referencing --- often found in the system registry).
|
| It's always a potential problem, regardless of "mitigating factors"
I think I am blessed in my CD-R/W software, as I never did notice that
particular problem. I have CEQuadrat PacketCD. But I may also just
drag/drop hdd to CD & back again. I'm looking now-- nothing that I
copied back after my hdd crash is Read-Only. Ah, ha, ha!
|
| >| Typically, the most common place to encounter a massive
SFN-collisions
| >| is in the cookies directory where the web browser (e.g., IE and
| >Mozilla) | saves cookies using a series of files whose name share the
| >| same beginning. Since the cookie files are always referenced by
| >| their LFN name, the SFN preservation for those files should not
| >| be critical.
|
| The big crisis will be...
|
| "C:\Program Files\Microsoft Office"
| "C:\Program Files\Microsoft NetMeeting"
| "C:\Program Files\Microsoft Windows Media Player"
| "C:\Program Files\Microsoft Did We Mention Microsoft Wrote This Yet"
|
| ...especially where registry or Path refs using underlying 8.3 abound.
Hmm. I think I'm reading that the 32-bit version of XXCopy anyway can
handle this when the destination folder does not already have a matching
SFN prior to the copy operation. Also, the destination folder must have
been created by the same OS.
|
| >| The most important SFN that should be preserved is the common
| >| ones such as "C:\Program Files\", "C:\Documents and Settings\".
|
| That's just the hem of a very rancid sock.
|
|
| >--------------- ----- ---- --- -- - - -
| Error Messages Are Your Friends
| >--------------- ----- ---- --- -- - - -
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
| Fascinating stuff on LFNs and XXCopy, etc.
|
| FWIW, some background stuff..
|
| http://users.iafrica.com/c/cq/cquirke/lfns.htm on LFNs
Cquirke, why can't I see that offline? It should be in my TIFs! (Other
stuff I viewed last night does work fine.)
|
| http://users.iafrica.com/c/cq/cquirke/dataman.htm/backup_issues on
| backup approaches and problems
|
|
| >| Hi, PCR;
|
| >| XXCOPY's /NX operation (it is a default setting) tries to preserve
the
| >| SFN that is associated with the source file at the destination file
| >| as much as possible. Since this feature is only an added "bonus"
| >| when XXCOPY finds a situation in the destination which does not
| >| easily accommodate the desired outcome, it gives up the effort on
| >| that file. There are a number of scenarios where the /NX operation
| >| fails. For example, when there is another file in the destination
| >| which already has the desired file name, then, XXCOPY will not try
| >| to vacate the desired SFN by renaming the existing one. Another
| >| scenario is when the source or destination volume is controlled by
| >| both Win9X/ME and NT/2K/XP families of Windows (e.g., with a
dual-boot
| >| system). While the first four SFN names are synthesized using the
| >| same scheme (starting with XXXXXX~1, XXXXXX~2, .... XXXXXX~4) by
both
| >| the 9X/ME family and the NT family, the NT-family Windows switches
| >| the algorithm using a 4-digit hexadecimal hash value (e.g.,
XXABCD~1)
| >| to avoid excessive SFN collisions.
|
| Can Win9x-LFN-algorithm Win9x read NT-LFN-algorithm LFNs?
I think he is saying the differences in the methods makes it impossible
for XXCopy to get it right 100% time in the circumstance of a mixed OS.
XXCopy will err on the side of safety & let the OS generate it's own SFN
in that circumstance. Can Win9x read WinNT? That is a different
question.
However, the implication is that they can coexist on the same OS. Or is
it? Can Yabumoto be talking about copying files to a folder that already
has files in it? Then, the folder had WinNT files but XXCopy is now
asked to put Win9x files into it. Can that be it?
|
| >| http://www.xxcopy.com/xxcopy08.htm
|
| <sigh> ...so many links, so little time...
|
| >| Another notable case is with the file system for the CD-R/W
| >| (packet-write) volume such as InCD and DirectCD. The file system
| >| for CD-R/W uses a totally different scheme to assign the SFN.
|
| For file names, period; the rules often clash. That (plus "why is
| everything read-only?") is why I advise against raw file copy to
| CDR(W) for all but the most trivial backup purposes. Wrap it in a
| .zip, benefit from CRC - but this will leave 8.3 names to be generate
| on the fly during restore, and thus LFN-8.3 ambiguity again.
|
| Using XXCopy in one direction doesn't help if you use something else
| in the other direction, and some DOS mode LFN tools are buggy.
I suppose Yabumoto purposefully did not write his own file system, but
only created a cache to trap SFNs for manipulation. Then, he would read
the destination to see what is there & try to arrange it so those to be
added would end up right (same SFN). Naturally, there were impossible
situations, such as the SFN was already there from a prior copy. Also,
XXCopy must be the one doing the copy for a greater chance to preserve
SFNs. But he didn't leave it so only XXCopy could be used. to make a
copy.
|
| >| Since XXCOPY uses a combination of standard file I/O API functions
| >| iteratively to manipulate the SFN in order to preserve the
| >| SFN (rather than using direct low-level device I/O operations),
| >| XXCOPY will give up the /NX operation when the SFN preservation is
| >| not possible.
|
| That suggests XXCopy can't manage LFNs in DOS mode at all ...?
There are two version of XXCopy. The "true" DOS version is not as
capable.
|
| >| Therefore, it is true that XXCOPY does not always succeed in
| >| preserving the SFN. However, we believe it is not critical in
| >| most situations (except when one tries to save the whole system
| >| volume into a CD-R/W volume and hopes to maintain the exact
| >| 8.3-name based referencing --- often found in the system registry).
|
| It's always a potential problem, regardless of "mitigating factors"
I think I am blessed in my CD-R/W software, as I never did notice that
particular problem. I have CEQuadrat PacketCD. But I may also just
drag/drop hdd to CD & back again. I'm looking now-- nothing that I
copied back after my hdd crash is Read-Only. Ah, ha, ha!
|
| >| Typically, the most common place to encounter a massive
SFN-collisions
| >| is in the cookies directory where the web browser (e.g., IE and
| >Mozilla) | saves cookies using a series of files whose name share the
| >| same beginning. Since the cookie files are always referenced by
| >| their LFN name, the SFN preservation for those files should not
| >| be critical.
|
| The big crisis will be...
|
| "C:\Program Files\Microsoft Office"
| "C:\Program Files\Microsoft NetMeeting"
| "C:\Program Files\Microsoft Windows Media Player"
| "C:\Program Files\Microsoft Did We Mention Microsoft Wrote This Yet"
|
| ...especially where registry or Path refs using underlying 8.3 abound.
Hmm. I think I'm reading that the 32-bit version of XXCopy anyway can
handle this when the destination folder does not already have a matching
SFN prior to the copy operation. Also, the destination folder must have
been created by the same OS.
|
| >| The most important SFN that should be preserved is the common
| >| ones such as "C:\Program Files\", "C:\Documents and Settings\".
|
| That's just the hem of a very rancid sock.
|
|
| >--------------- ----- ---- --- -- - - -
| Error Messages Are Your Friends
| >--------------- ----- ---- --- -- - - -
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
P
PCR
I am not an expert in XXCopy. You must go to the site and see whether
there is a write-up on a full-system XXCopy one hdd to another. Maybe
Yabumoto has it covered.
http://www.xxcopy.com/
(a) Rod Speed has sworn XXCopy will not copy the Swap File (Win386.swp).
However, he is a tad unclear as to whether he is speaking of the 32-bit
Windows version or of the complementary 16-bit DOS version.
(b) So, did you use the 16-bit or the 32?
(c) It is SFN woes in question, not LFN. I am fairly confident the
32-bit version handles it, under the circumstance you may have used it,
but doubt the 16-bit will.
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
| Angelo Campanella wrote:
|
| > I have solved that problem by having a second hard drive that
can be
| > connected as a storage medium. I then use XXCOPY to make a clone of
my
| > existing hard drive. The spare drive must have a capacity same or
larger
| > than the space you are occupying as the regular hard drive. After
| > copying the cloned version back onto the hard drive (or another you
want
| > to use as the main drive), Windows 98 can be self- booted from that
| > after about two or three trys at same. W98 seems to "heal" or "grow"
| > itself to work OK that way!
|
|
| Allow me to follow-up this article subsequent to various comments on
same.
|
| 1-
| True, my boot tries were muddled by the existing swap file, I suspect.
And true,
| one can delete it to give the old windows system a new try at same, so
there is
| no confusion there.
|
| 2-
| All my long file names remain intact (plain W98). So there is reason
for concern
| there at all. As a matter of fact, the only time I see short file
names now is
| because I am still a DOS freak, and I have oodles of DOS apps on my
desktop as
| icons. And I love to do my directories-dancing in DOS (where short
file names
| are often displayed) since I know my way around them.
|
| 3-
| The XXCOPY method has been a real life-saver. It does, however require
that your
| hardware include a multiple disk connection.
|
| Angelo Campanella
|
there is a write-up on a full-system XXCopy one hdd to another. Maybe
Yabumoto has it covered.
http://www.xxcopy.com/
(a) Rod Speed has sworn XXCopy will not copy the Swap File (Win386.swp).
However, he is a tad unclear as to whether he is speaking of the 32-bit
Windows version or of the complementary 16-bit DOS version.
(b) So, did you use the 16-bit or the 32?
(c) It is SFN woes in question, not LFN. I am fairly confident the
32-bit version handles it, under the circumstance you may have used it,
but doubt the 16-bit will.
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
| Angelo Campanella wrote:
|
| > I have solved that problem by having a second hard drive that
can be
| > connected as a storage medium. I then use XXCOPY to make a clone of
my
| > existing hard drive. The spare drive must have a capacity same or
larger
| > than the space you are occupying as the regular hard drive. After
| > copying the cloned version back onto the hard drive (or another you
want
| > to use as the main drive), Windows 98 can be self- booted from that
| > after about two or three trys at same. W98 seems to "heal" or "grow"
| > itself to work OK that way!
|
|
| Allow me to follow-up this article subsequent to various comments on
same.
|
| 1-
| True, my boot tries were muddled by the existing swap file, I suspect.
And true,
| one can delete it to give the old windows system a new try at same, so
there is
| no confusion there.
|
| 2-
| All my long file names remain intact (plain W98). So there is reason
for concern
| there at all. As a matter of fact, the only time I see short file
names now is
| because I am still a DOS freak, and I have oodles of DOS apps on my
desktop as
| icons. And I love to do my directories-dancing in DOS (where short
file names
| are often displayed) since I know my way around them.
|
| 3-
| The XXCOPY method has been a real life-saver. It does, however require
that your
| hardware include a multiple disk connection.
|
| Angelo Campanella
|
P
PCR
Well... you mean... no, no, pay no attention to my limp... I always play
that way!
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
|
| |
| > Really, I came to play baseball with Campanella.
|
| Obvious lie.
|
|
| > | > |
| > | | > |
| > | > Well, you are tough to please, Rod Speed.
| > |
| > | Wrong. As always.
| > |
| > | > But I never did come here to please you.
| > |
| > | Wrong. As always.
....snip
that way!
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
(e-mail address removed)
|
| |
| > Really, I came to play baseball with Campanella.
|
| Obvious lie.
|
|
| > | > |
| > | | > |
| > | > Well, you are tough to please, Rod Speed.
| > |
| > | Wrong. As always.
| > |
| > | > But I never did come here to please you.
| > |
| > | Wrong. As always.
....snip
B
Bill in Co
PCR said:I am not an expert in XXCopy. You must go to the site and see whether
there is a write-up on a full-system XXCopy one hdd to another. Maybe
Yabumoto has it covered.
http://www.xxcopy.com/
(a) Rod Speed has sworn XXCopy will not copy the Swap File (Win386.swp).
WHY on earth would ANYBODY want to copy the Swap File?
E
Eric Gisin
You didn't answer the question. Why kind of retard would copy the swap file?
| It's been know to happen.
|
| (e-mail address removed)
| | WHY on earth would ANYBODY want to copy the Swap File?
| |
| It's been know to happen.
|
| (e-mail address removed)
| | WHY on earth would ANYBODY want to copy the Swap File?
| |
R
Rod Speed
Well... you mean... no, no, pay no attention to my limp...
I always play that way!
Another obvious lie.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.