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

Number   :  3466
Date     :  2003-01-06
Author   :  Kan Yabumoto
Subject  :  Re: How is the /IN supposed to work?
Size(KB) :  3


c.r.p:

In earlier version (the one you are using), XXCOPY operated
almost exactly like XCOPY with regard to the source specifier.

That is, when you did not specify any lastname pattern in
the source specifier, XXCOPY automatically assumed "*" (everything)
inside the directory. This behavior was there even after
we introduced the /IN feature. So, having "*" in the source
specifier (implicitly), it overshadowed all other /IN settings.
That is what was happening in your case.

At that time, we wanted to deal with the problem using some
"bogus" pattern which is guaranteed to be absent. We experimented
with the reserved filename "NUL" (DOS/Windows treats this word
specially and you cannot have such a file name but it serves
a useful purpose from time to time in batch file).

So, with earlier versions (I wouldn't be surprised that it
works with the earlier version like v.2.80.3), we were quietly
using the name "NUL" for the "bogus" pattern for almost exactly
the same purpose as you did.

xxcopy d:\nul c:\temp /IN*.dbt

That was our way to deal with the problem at first. But,
we were non-committal to this idea because it was an ugly
solution. Later, after we re-examined the option, we chose
the scheme that is already there with Robocopy.

If the source specifier does not have the lastname pattern,
then, the "*" (everything) pattern will be assumed only when
no other /IN parameter is specified.

What I explained to you in my earlier message is true in
more recent versions of XXCOPY. Actually, I'm glad that
we chose not to document the "NUL" feature at the beginning.
It was quietly brought in and after our internal usage, we
chose to discontinue it quietly. This new behavior was
introduced (quietly) in v.2.82.2 (July, 2002). This current
scheme of selective assertion of the "*" pattern when no /IN parameter is 
found is probably the optimum solution to this.

So, whether you like it or not, we have to improve XXCOPY.
And, if anyone does not like to use the new version, that is
fine. But, from time to time, our explanation of features
may not apply to the old version you use. Generally speaking,
this is the reason why we indirectly suggest an upgrade.

Currently, we are trying to make the new series of the
beta version as the basis for our next big release.
The new beta test series that has v.2.83.x has a clearner
inside everywhere for which we worked for over six months.
Although we had a few minor glitches in the first few
attempts, the latest one 2.83.4 seems to be holding up.
(Since we always say the latest one is the greatest,
no one believes us on this. Even we ourselves cannot
say a beta release version is stable until it remains
unchanged for a few weeks).


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

At 2003-01-06 11:40, you wrote:
>As far as the age factor goes, our company goes by the adage that if
>it ain't broke and you don't see how an update would be an upgrade,
>then don't change it. It was only last month that we moved our main
>server off of nt3.51
>
>As for the /IN, i still couldn't get it to do what i wanted even when
>i took out the first '*', but then realized if i used an bogus
>extension for my first part, xxcopy would copy nothing but the /IN.
> xxcopy d:\*.999 c:\temp /IN*.dbf
>worked fine.



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