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

Number   :  6563
Date     :  2003-12-19
Author   :  Kan Yabumoto
Subject  :  Re: "RmDir failed" messages when running /RCY
Size(KB) :  3


starman617 wrote:

> I wasn't writing about the cosmetic appearance of /PB but
> the fact that including /PB with the /RCY seems to cause
> the "RmDir failed" messages whereas running XXCOPY with /RCY
> and without /PB does not give the error.
> I have read all the posts on this thread to this point.

You are absolutely correct.
I guess I was not very careful reading the posts.

I was mixed up the /PB-/RCY comb bug that you reported
with the /PB: feature which had the (cosmetic) bug
that did not correctly processing the progress-bar-for-file
threshold. My previous references to the /PB bug was
talking about the threshold bug. Now, for the first time,
I understood what you were pointing out.

So, I went back and tested the /RCY/PB operation and
sure enough I saw the bug. To be honest, ever since the
/PB feature was introduced (almost 3 years ago), this
combination was never run on our machines and the bug
has survived over 200 revisions in the source code!!!
Probably this is the oldest bug that eluded our
detection !!! I'm quite speechless.

As to the question of whether this is cosmetic in nature,
it is definitely not. On the other hand, the consequence
of this behavior seems to have always been not very serious.


A lovable bug!
--------------------------------------------------------
For those who saw the extra prompts or funny failed
RmDir messages that this bug was spewing, this must
have been very puzzling to say the least. Even I was
puzzled by looking at the screen. When I examined
the code and where and how this funny message was
generated, it made a lot of sense.

If you are curious on how this behavior came about,
let me explain what was happening. In order for XXCOPY
to generate the progress bar, it has to know the
total byte count of the entire job. The only
practical way for a complex program like XXCOPY
(considering the exclusion feature and extra directory
traversing for wild-wildsource feature) is to run the
entire command twice --- the first pass will simply
identify which files will be selected and the file
count and the total byte count are computed. Remember
that XXCOPY has the /ED0 feature (to remove empty
directories unless /ED is set). So, when directories
are traversed with /PB, it tries to remove the
directory as the last step after the contents of
a directory is processed. Now, with the /PB switch,
every directory is visited twice (the first pass
is a dry-run). With this bug, XXCOPY was trying to
remove the directory even in the first pass.
Since this was near the end of the function and
was a small item in the code (with poor commenting),
the "remove the directory" operation was run twice
(complete with the confirmation prompt and the
report of the failure). Like almost any other bug,
even a strange looking behavior makes sense once
the mechanism is fully exposed.

But this bug was a cute one with hardly any ill-effect.
And, it survived a long time. It took only 13 more
characters in the source code to kill this bug. R.I.P.
-------------------------------------------------------

I'm a little embarrassed to acknowledge this bug
and more on my not reading the bug report carefully :-(

Thank you for your persistence in explaining this.
The fix is on its way.

Kan Yabumoto



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