[<<]Message[>>]    [<<]Author[>>]    [<<]Subject[>>]    [<<]Thread[>>]

Number   :  3165
Date     :  2002-12-01
Author   :  Kan Yabumoto
Subject  :  Re: tripping xxcopy-corrupting filenames
Size(KB) :  4



Douglas:

We are not aware of a bug of this nature. As you may know, XXCOPY
does not have a rename feature. On the other hand, the /NX operation
(to preserve the SFN --- a default behavior unless you disable it by
/NX0) involves a series of renaming operations in order to have the
file system match the SFN as in the source directory. Still, the only
explanation we have for the strange behavior is either a bug in
XXCOPY which no one has seen before, or other factor outside of
XXCOPY. The only other explanation is that your system is very
unstable where a memory contents changes arbitrarily. But, it this
happens with any repeatable (albeit, unpredictable) fashion, I imagine
your system would not be stable enough to perform any serious
operation. So, in essence, I don't have a good explanation for
your observation.

What I suggest as a starting point, is to establish whether the
problem is repeatable exactly. For example, I would set aside
a test directory with sufficient variations (with varying filename
patterns --- short, long, very long, etc.) with some levels of
complexity in the subdirectories. Since the problem seems to
be in the filename, I would not make the files very large --- but
making a large number of files and directories may help. Then,
make a batch file with simple and complex file-selection options.
(start with simple command and make it more complex as necessary).
Play around and experiment to better characterize the problem so
that you can list the necessary condition for the problem to
appear in a consistent fashion.

Usually, it is good idea to keep the debugging operation as simple
as possible. That is, if you find a set of XXCOPY command and
the set of files which causes repeatable problem (it is easier
to pinpoint the problem with the smallest set of options), then
you remove one switch at a time to reduce the complexity. Both
in the nature of XXCOPY operations (i.e., less switches) and
the scale (# of files and # of directories) without eliminating
the repeatable problem. Your careful observation during this
process will usually lead to a narrow set of conditions that
cause the problem.

If your system operates in a very random and inconsistent way
(e.g., you may not be able to create a repeatable problem),
I would look for a cause that is unrelated to XXCOPY.
Viruses, corrupted file system (make sure you run scandisk
so that the experiment is always run on a healthy volume).

If you are using a "live" data where the set of files you
are dealing with changes from run to run, it will make the
experiment more difficult to reach a conclusive result.

Kan Yabumoto
=========================================================

At 2002-12-01 10:50, you wrote:
>I am using the freeware version of xxcopy (ver2.82.3) and am impressed 
>with its
>versatality and also the advice given here. But I am getting some data 
>corruption of
>such an unusual nature that I wondered if it could be attributed to 
>something I am doing
>wrong.
>I am using it to delete files in the target directory which are identical 
>to the source, and
>then all files except .zip files in that directory, which are then copied 
>to another directory
>before being overwritten. The idea is that anything that I have zipped 
>should not have
>altered, and if it has I want to save the original copy in the back-up 
>directory.
>But I am getting a strange type of error on the target drive; occasionally 
>a file is
>renamed so that one letter in the name is increased by one, so 
>autoexec.bat can
>become autoeyec.bat, and something.gif can become something.hif, and once 
>a digit
>was increased by one.
>Now xxcopy sometimes gives me prompts about deleting the directories, and 
>I have
>sometimes killed it by Ctrl-C; also I have a pause control in my batch 
>file for unexpected
>error levels when I also use Ctrl-C. Last time I did this I had run 
>scandisk (USING
>wIN98) a day or two before and had not accessed that drive. On rebooting 
>my file-
>structure was again corrupted and my dos-based virus checker started 
>running all over it
>(it runs on detecting changes in the boot sector).
>Any thoughts to narrrow down the cause?
>Douglas Holden



This message if part of XXCOPY's message Archive.
The archive contains all the messages posted at Yahoo!Groups: XXCOPY.