I'n confused;

when I asked if xxcopy could determine do that I was
told know. You just solved my problem

If I use /qf:650m to a temp dir and subdirs then I
will have the size I need for my CDs right?

I assume if I start xxcopy again in the batch for
example if I first copy files to martialartshtml then
copy to htmltipsandtricks then the count will start
again correct?

Rick


--- Kan Yabumoto <tech@...> wrote:
>
> Ray:
>
> Let me take care the second feature you mention
> first.
>
> You asked for /MAXBYTES:500M  which would stop after
> reaching the
> 500MB limit.  Yes.  We already have exactly like
> that in the
> current beta test version v.2.90.4  (since ver 2.
> Actually, there are a series of similar switches
> (/Qxxx)
>
>    /QF  Quits when the quota for the file count has
> been reached.
>   /QBL  Quits before the byte count exceeds the
> limit (same as /QB).
>   /QBT  Quits when the total byte count reaches the
> trigger point.
>   /QSL  Quits before the space dips beolow the limit
> (same as /QS).
>   /QST  Quits when the remaining space reaches the
> trigger point.
>
> For the byte-count related operation, we provide two
> variations:
> /QBL  sets a maximum limit which would not be
> exceeded.
>        It is useful when the limit cannot be
> exceeded (say you
>        are creating a directory which has a limit of
> 1.44 MB
>        which would store a set of files for eventual
> transfer
>        to a floppy disk (or CD-R).
>
> /QBT  sets a trigger point which will signal the
> last file
>        transfer.  This is probably what you had in
> mind.
>
> The /QSL and /QST are tied to the space left in the
> destination
> volume.  They are sometimes useful when you want to
> leave
> some room in a removable media (rather than let it
> be full).
>
> So, /QBx and /QSx has a pair of similar operations.
> One may wonder why there is only one kind for /QF.
> The
> answer is that you don't need two variations because
> the
> total file count is always incremented by one and
> therefore
> you need not consider a range in defining the limit.
> Whereas total byte count is incremented by the file
> size
> which varies and therefore the limit can be
> interpreted
> in two ways.
>
>
-------------------------------------------------------------
>
> As to the other feature, to set a time limit on a
> job.
> It is not a difficult feature to add.  The question
> is
> who else really need it?  (This question is silly
> because
> if you need it now, someone else may want it later.)
> A better question is how badly do people really want
> it?
>
> (Hint: our list of priority is often tied to the
> revenue
> potential of the feature).
>
> As always, when you ask for a feature, our natural
> reaction
> is to think of how we can generalize it.  In this
> case, we
> would immediate think of setting the limit by
> duration
> (as you proposed) and an absolute point in time
> (like finish
> it by 4:00 am).  That's how XXCOPY evolved
> uncontrollably.
> But, by adding similar functionality at once will
> give
> uniformity and symmetry in the XXCOPY command set.
>
> We will put it in our list of Things-to-do.  I can't
> promise
> how soon it will become a feature.
>
> Kan Yabumoto
>
===============================================================
> At 2002-01-31 14:09, you wrote:
> >I'd love if xxcopy came with switches that would
> terminate the
> >copy after "x" minutes or "x" bytes copied, even if
> the files weren't
> >finished.
> >
> >example: xxcopy c:\ \\remotecomputer\backup\
> <\\remotecomputer\backup\>  /s
> >/maxtime:3600 /finfile
> >where remotecomputer is over a slow WAN link and
> would terminate
> >the copy after 3600 seconds, but finish copying the
> current file.
> >
> >or
> >xxcopy c:\ \\remotecomputer\backup\
> <\\remotecomputer\backup\>  /s
> >/maxbytes:500M
> >where the copy would terminate after 500 Megabytes.
>  The file
> >that was in the middle of being copied would NOT be
> finished,
> >and thus deleted from the destination.
> >
> >Thanks!
> >Ray
>
>
> ------------------------ Yahoo! Groups Sponsor
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


=====
http://www.hometutor.f2s.com/tutoring
http://www.martialartists.f2s.com/martialarts
http://www.martialartists.f2s.com/ebooks Obesity in Children, Anger Management,
Internal Energy Strikes, meditation & More
http://www.martialartists.f2s.com/sellmyebooks
http://www.hometutor.f2s.com/qualifications
http://www.hometutor.f2s.com/emagazines Tutoring Behavioral Problems Weightloss

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com

--- In xxcopy@y..., Kan Yabumoto <tech@x> wrote:
> In this case, we
> would immediate think of setting the limit by duration
> (as you proposed) and an absolute point in time (like finish
> it by 4:00 am).

the task scheduler built into windows 98, me, 2k, and xp. will do
both of these functions.

-----

regarding quantity limitations, kan, how would you deal with this
situation: the total file quantity to be copied is 800mb and the
available space is 500mb. at the 350mb point of the copy process, the
next file to be copied is a large single 300mb file. this
triggers 'out of space'. will you stop or merely skip this file and
continue on with the copy session? if you continue, then the
principle of skipping files that are to large for the ever
diminishing hole continues until the very last cluster is taken. this
could potentially cause a session to run very long as it continues to
scan the source for an eligible file to copy. and the resulting
destination directory structure could be very convoluted with only
patches of scattered small files.

i'm not sure that this is necessarily bad, but one would need to be
aware of this behavior when using such switches.

I hope that the pro licence for "one" computer does/will permit use for file
transfer between a portable and a second machine but exclude any other
simultaneous use of the software.

I may be drummed out for this, but I think the FW version contains more than
the great majority of potential users need or could use without help.  For
the pro version, the 60 day trial is surely enough to convince any potential
purchaser of its value.

Most of the requirements for W9x "cloners" would be met with a reduced
version of XXCOPY containing only the following switches: -

/CLONE
/EZCOPY ( this is /CLONE incorporating Z0 instead of ZY)
/RMDIR
/SP
/L

Such a FW version of XXCOPY listing only these five switches (although
presumably also containing their component switches) would need simpler,
long life editions of  XXFW "User manual" and "FAQ" bulletins than does the
pro version of XXCOPY.  The FW version should then generate little, if any,
need for support from Kan or this group.

Replacing the current FW with this subset for use on a single, personally
owned, stand alone, machine should help to separate the mass market from the
specialist niche which Kan needs for ongoing revenue.

P.S.  How about EZCOPY in all versions?  It's easier than
/KS/H/E/R/Q/Y/BI/Z0/ZE and further reduces any potential confusion arising
from the use of /CLONE/Z0

regards,

Bob Weir

Please read the doc very carefully.

/QF is to count the number of files, not the total bytes.

/QF:650M  as you typed will quit only after it copies 650,000,000
files are copied.  I haven't seen any one who has this many files in
one volume.

For CD, what you need is /QBL550M  (I'm not sure the exact limit
on the CD-RW using the DirectCD format which is substantially
smaller than the other CD-R format).

XXCOPY does not have a built-in smart thing to start the next
job where the first one left unless you use other mechanism
such as using the Archive bit to mark what's done and what's not
(as you have demonstrated to others in your earlier message).

-----------------------------------------------------------------

Incidentally, please be careful about the colon which separates
the command letter part.  Traditionally, XXCOPY never used
a separator between the command-alphabet part and the associated
parameter parts.  For example,

    /X*.doc          // to specify "*.doc" as an exclusion specifier.

But, in a limited context such as

    /D:2002-02-01   // select files made on or after February 1st

This was for the XCOPY-compatibility's sake.

The reason for not adding any separator was simply to conserve
the space needed to specify things in the command line which was
once very tight.  That was exactly why XCOPY (and of course, XXCOPY)
allows you to combine two or more switches without a space
in between.

    /S/H/ONc:\mydir\mylog.txt

The introduction of the /CF switch (command file) which allows you
to specify an unlimited length of command text in a file.  Now, with
the command file, we encourage the user to use the space more
generously.  We suggest to use one command per line with a comment
(starting with // ) on each line.

Therefore, now, the legibility should be given some consideration.
That is why we have gone the trouble of allowing the colon character
as an optional separator between the letter-part and the associated
parameter to the command switch.

In the upcoming release (which we have been testing in-house),
nearly all commands (with a few unavoidable exceptions for
historical reasons) will allow the optional colon as a separator
and we will start recommending its use.

Therefore, /QF:150m will be accepted starting in the next beta test
release.  But, not the current beta release version (v.2.90.3)
was in transition and only half of the commands were converted
(/QF:150M is allowed).  Since not all of them accepts the colon
separator, let us refrain the use of the colon until it becomes
official in the beta test version.

* * * * * * * * * * * *
    S U G G E S T I O N
* * * * * * * * * * * *

By the way, we have all seen enough of your martial art links
at the end of your messages.  According to the good old netiquette,
a signature section should be up to four lines (preferably three).
But in here, we do not really appreciate any of them.
Sure the Yahoo people place their ads at the end of the Emails
that they deliver.  But, they are considerate enough to remove
the ads in the archived text.  Unfortunately, the Yahoo archival
does not have the intelligence to remove your signature lines.
As a consequence, the archived messages have been polluted by your
martial art links which are not only irrelevant to this group
but just plain redundant and we all suffer.  I keep all the
messages that I receive as Email and my hard disk has
accumulated quite a few lines of your martial arts things by now.

Yes, it had the effect and I have visited your web site once.

In my own posts (a few messages ago), I inadvertently forgot
to delete your signature lines from my reply.  And, when you
replied to mine,  we saw twice the mess (and they were all
archived!!!!).  The Yahoo ads they add will always be removed
from the archived text even if you accidentally forget to
remove from your reply.

So I beg you to stop sending any more message that has your
martial art things.  I hope you do not take this personal.
I just got sufficiently irritated that I had to voice this
point (I wish I have read your "Anger Management" stuff).

OK, as a compromise, let me propose to *ALL* members in
this group that in order to acknowledge the contribution Rick
made to this discussion group, that we all visit Rick's
one-of-a-kind Martial Arts paradise.  If you haven't seen it,
it's worth a visit.  The construction of his web site is a piece
of (martial) art.  It demonstrates what one can do with the
HTML language.  I kid you NOT.  In a sense, Rick pushes the
frontier in the art of web site design to its limit just
as XXCOPY pushes its limit in its quest of its own.

Just go to this one: http://www.hometutor.f2s.com/tutoring
And enjoy the ride (it take a few minutes) with a seatbelt.

Rick, is the photo at the top left yours?  The photo could be
a little sharper.  But, I can see you're a good looking man.

Rick, when all of our members have visited your site once,
you should have no reason to continue your daily Karate Chops
to our board.  Thanks.

Have a nice day.

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

At 2002-02-01 02:24, you wrote:
>I'n confused;
>
>when I asked if xxcopy could determine do that I was
>told know. You just solved my problem
>
>If I use /qf:650m to a temp dir and subdirs then I
>will have the size I need for my CDs right?
>
>I assume if I start xxcopy again in the batch for
>example if I first copy files to martialartshtml then
>copy to htmltipsandtricks then the count will start
>again correct?
>
>Rick

At 2002-02-01 07:37, mchampfl wrote:

>--- In xxcopy@y..., Kan Yabumoto <tech@x> wrote:
> > In this case, we
> > would immediate think of setting the limit by duration
> > (as you proposed) and an absolute point in time (like finish
> > it by 4:00 am).
>
>the task scheduler built into windows 98, me, 2k, and xp. will do
>both of these functions.

That's true.  But, can Ray's original wish come true by that?
In other words, XXCOPY could incorporate a feature which checks
the duration of the current job or the current time against
it's absolute time limit whenever it is ready to start a new
file-copy operation and terminates gracefully if the time is up.

On the other hand, are you saying that the built-in Windows
mechanism (Which I never used it in such a way) can kill the
on-going XXCOPY task by aborting the process in the middle?

I suppose if that is what the task manager does, it's equivalent
to press the Ctrl-Alt-Del combination and kill the running
XXCOPY program in the middle.  I'm sure it could be done but
it will not let XXCOPY clean up the log file, etc.

Now, let me add clarifications here.

>-----
>
>regarding quantity limitations, kan, how would you deal with this
>situation: the total file quantity to be copied is 800mb and the
>available space is 500mb. at the 350mb point of the copy process, the
>next file to be copied is a large single 300mb file. this
>triggers 'out of space'. will you stop or merely skip this file and
>continue on with the copy session? if you continue, then the
>principle of skipping files that are to large for the ever
>diminishing hole continues until the very last cluster is taken. this
>could potentially cause a session to run very long as it continues to
>scan the source for an eligible file to copy. and the resulting
>destination directory structure could be very convoluted with only
>patches of scattered small files.

I think I have made some discussion with an elaborate example
about this topic.

http://groups.yahoo.com/group/xxcopy/message/1076

As I demonstrated in the message, an intuitive solution of skipping
one and stuffing the next one is not always the most efficient way
to find the true optimum.  It may appear to give you an advantage
most of the time.  But as my example demonstrates, the problem is
a lot more complex than a simple, intuitive scheme seems to provide.
To do it completely right, one has to even undo what have already
been copied to the destination and see if the next combination
of files would leave less waste in the end.   In other words,
Stuffing the destination with larger file first does not always
give the optimum solution if the goal is to minimize the wasted
space on the destination.

   ---------------------------------------------------------------
    Again, it's a well-known algorithm problem.  The truth is to
    do it perfectly right it will take too much computer time.
    Here's a brief explanation (we are not talking about 10 or
    20 minutes, we are talking about 100 years or 10 billion
    years of computation, no kidding).

    Since the number of files we are dealing with is always
    finite, there is only a finite combinations of files to
    stuff in the destination volume.   One way to
    do it right is to calculate every one of the combinations
    and find which one gives the least amount of waste in
    the destination volume.  Since the combination is finite,
    there is always an answer (could be many ties).  But, when
    the number of files that we are dealing with is just a few
    thousands (or even a few hundred), the number of permutations
    are just mind boggling.  It will be totally out of question
    to use this brute force algorithm to find the optimum.
    I'm sure there are in-between, quick-and-dirty algorithms
    that give you pseudo-optimum solutions.  But, I don't know
    of any agreed-upon scheme which gives you consistently
    good results.  The intuitive answer which many people come up
    (like the one you suggested) is definitely not the answer.
    My simple example above offers one counter example. And for
    a proof, one is enough.
   ---------------------------------------------------------------

In conclusion, XXCOPY does not try harder when it find time
to stop.  As simple as that.

Of course, if we abandon the notion of "optimizing" the stuffing,
the situation is dramatically different.  That is, we simply
follow a clear and simple algorithm (a scheme if you will).

Probably the only one that come to my mind right now is to
pick one file (according to the native order in the directory
whatever the underlying file system provides) and if it fits,
then it will be copied and if not, it will be skipped
and go to the next one.  No back-tracking or even an attempt
for sorting in any way.  That is relatively straightforward.

   ---------------------------------------------------------------
    By the way, a number of people wanted to have XXCOPY follow
    some sorted order in file operations, notably, alphabetic,
    by-size, by-date, by-filename-length.  The good news is
    we are working toward that direction.

    XXCOPY processes the files and directory on-the-fly without
    accumulating them into a buffer.  On the other hand, as a
    programmer with sufficient insights, I can easily tell how
    Robocopy operates;  it captures the whole directory contents
    (one level at a time) into its internal buffer (creating a
    table of data) and selects items from the list.  This kind
    of approach is more suitable for operations that require
    sorting.  For one thing, the program probably looks a lot
    more manageable --- one thing at a time (but I can see a
    subtle bias in their design that restricts their way of
    adding nifty features as freely as we do with XXCOPY).

    The draw back is what if you run out of room in
    memory to keep all that stuff.  In the Win32 environment,
    especially with NT/2000/XP environment (Robocopy does not
    even run under Win9x) we never really have to worry
    about space in memory any more.  But we are still supporting
    XXCOPY16.  With the severe 640 KB limit with potentially
    a large number of files kept in one directory, it is easy
    to see XXCOPY16 encounters an out-of-memory situation
    quite frequently when you start saving the directory contents
    in a private table.  My guess is that we will have to abandon
    some feature-compatibility in XXCOPY16 when this kind of
    situation arises.  It was the memory-tight DOS tradition
    of XXCOPY16 that forced to use the very efficient (a little
    more complicated in programming) on-the-fly processing of
    directory data by the XXCOPY program.
   ---------------------------------------------------------------

But, I have a resistance to this idea in my mind (to skip
some file or to disregard the "native" order of the files in
the directory)

That is the awkwardness in making a tag to a file which has
been processed so that in the next round, files are selectively
skipped by the tag.  Currently you can use the archive bit
for this purpose but it's far from elegant.  I just don't like
the mess yet, I don't have alternate solution to offer.

Sorry for lots of ideas and less clear conclusion...

Kan Yabumoto

For some reason I stopped receiving xxcopy posts.  I subscribed under
another email address so we'll see that if fixes it.  Unfortunately, during
the lapse, I missed all the message regarding backing up NT and shared
files.  I thought I'd add my two cents worth even though the topic may be over.

I have worked with NT 4 for many years and now I am working with 2000 and
XP.  As far as backing up these systems, I can sum up all my experience in
one simple statement:

"The only way to truly backup a system with open and locked system files is
to use another system"

Allow me to explain.  The main issues with backing up NT are locked files,
access to NTFS and long file names.  While it is possible to work around
some of these issues, you need to overcome all of them to achieve a
successful backup.  This only really leave two solutions .

The first is to image the whole partition using Ghost or something
similar.  In some situations, that is acceptable and works just
fine.  However, if you don't want to do that, there is one other
option:  Install a second a copy of NT and use that - quite simple ;)

Here is how I partition and build my personal workstations:

Drive 0:
Partition 1 - 2 GB NTFS (Primary OS)
Partition 2 -  500 MB FAT (Secondary OS)
Partition 3 - Remainder of drive NTFS (All Data)

Or if you have two hard drives:

Drive 0:
Partition 1 - 2 GB NTFS (Primary OS)
Partition 2 - Remainder of drive NTFS (All Data)

Drive 1:
Partition 1 - Whole drive NTFS (Secondary OS)

The secondary OS is simply a stripped down install with basic network
connectivity.  The second OS serves two main functions.  The first is to
provide a mechanism to fix the primary OS in the event it will not
boot.  If you use compatible OS, you can mount the registry, disable
drivers, change passwords, etc, etc.

The second function is to you enable you to perform a 100% guaranteed
backup of the primary OS.  Since you have network connectivity, you could
use xxcopy to dump it on another server somewhere.  You can burn a CD, copy
to a zip drive, do anything you want.  Many of these functions can not be
achieved from a boot disk and/or command line mode because of the three
problems I noted above.

By separating the actual OS from your data files, it also makes upgrades
real easy.  When I want to reinstall, upgrade or overhaul my system, I
simple wipe the entire C: drive.  I reinstall the OS, install my apps again
(yeah, this is still a pain) and all my data is left intact because it was
on an entirely different partition.

In the case of servers, the 2nd OS has saved the day many times.  I have
had situations where the primary OS suddenly would not boot for what ever
reason.  I simply boot the 2nd OS, change IP and machine name, fix any
permissions and shares, and now the server is back on line.  Most of the
time, the major concern is getting the data onto another system and/or
making a backup.  This is easily achieved now as you have a working OS with
full access to the data partition.  Even if the system partition is
corrupt, you are OK because the important data was on the other partition.

Finally, my backup scheme consists of a nightly "clone" from one drive to
another drive.  In the event my drive 0 totally fails, I can put in a boot
disks, point the boot.ini to drive 1 and I can boot my PC and have FULL
access to ALL my data from the day before.  All my systems have two hard
drives so I never have to back up to tape or another server.

As for backing up the registry, I use "regback" from the resource kit.  I
have posted a message on this in the past with details and examples on how
this work.  Search the archives and you should find the message.  If not,
drop me a line and I'll send it to you again.

Regards,

rotaiv.

--- In xxcopy@y..., rotaiv <rotaiv@b...> wrote:
> Install a second a copy of NT and use that - quite simple ;)
>

excellent idea!!!!

Dear Bob:

Thank you for your suggestion.

  >Replacing the current FW with this subset for use on a single,
  >personally owned, stand alone, machine should help to separate
  >the mass market from the specialist niche which Kan needs for
  >ongoing revenue.

Certainly, that is one way.  If my ultimate goal is to
reduce the tech support Emails that come to us or to this
group, some of your suggestions are pretty good.

But, my goal is not that.  My goal remains to increase the
popularity of XXCOPY.  (And, I want to reduce some of my
time here which is hard to do really and is contradicting).
So, I would add a new switch like /EZCOPY (for some reason,
I like /SYNC better) for the safer alternative, /CLONE/Z0
and promote that switch more to lower the false expectation
that the word /CLONE seems to evoke.

But, I'm very reluctant to "reduce" the number of features from
any of the packages.  I can hide more of them in some clever way.
It is true maybe 98% of users who hear about XXCOPY /CLONE
are relatively unsophisticated and barely competent to open a
DOS Box.  They are unlikely source of our revenue.  But,
the fact the remaining 2% of those who try XXCOPY /CLONE
will also discover the less well-known features, the real XXCOPY.

That is how our business is now going.  And, any effort we
do have to focus on this aspect.   Therefore, any scheme of
packaging has to make sure we will never reduce this small
but very important segment of users.  So, I have to live with
the load of tech support.  As an extreme argument, I would
rather stop responding tech support Emails than deliberately
try to reduce the Emails from coming.

I am afraid that any new package with a deliberately simpler,
and easier-to-use-for-beginner version will give a message
to unsuspected users that that is what XXCOPY is all about.
I can live with the criticism that XXCOPY is intimidating.
Our revenue source is those who get intimidated but
because of their professionalism, they overcome that hurdle
and become our customers.  And we are eager to repeat our
help.

In a sense, I'm contradicting myself by saying we want less
time spent on tech support.  Because our good tech support
is probably what impresses our potential customers and
convince them to pay significant amount of license fee.

I think what we need more than anything is to come up with
a one-trick-pony in GUI.  That will solve most of the beginner
problems more elegantly and correctly.  Then, we will also
have the professional version of GUI.  But, this GUI in
my vision need not be a full-fledged GUI-based application.
At least, I can bring out a quick-and-dirty (but fairly complete)
version of GUI that gives a well organized presentation of
*ALL* available command switches in a pull-down menu and
context-help so that a proper set of command line will be
"compiled" using the GUI front end.  I really believe that
many professional continue to use scripts.  And, everybody
has his own favorite way of constructing the scripts.

I believe I'm still on the right track by resisting the idea
of coming up with my own language and my own scripting rules.
(I may add a few very limited set of "flow-control" inside
the /CF file.  But, it is a can of worm.)

So, the next step is GUI.  No question about it.
But, I'm a obsessed perfectionist in programming and its
design.  I'm quite stubborn is many things.  I belive if
I abandon this principle, XXCOPY will be uncontrollably buggy.
And, I still need some minor ends to clean up (most of which
cannot be seriously called "new features" from outside).
I have a lot of clean up to do in the core section of the
program (which is running well if not quite fragile).  Also,
I need to remove the mess in the /X switch specification.
The ideal /X feature must be in the spirit of Wild-Wildcard.
The awkward documentation for the /X switch speaks volume on
the weak point.  No matter how well I write the documentation,
the ugliness of the design won't go away.

Another project that I'm quite serious about is the need to
overhaul the entire command set.  It will be a painful
step for old timers.  But, some of the command-letter assignment
is just unacceptably bad to my taste.  If XXCOPY has good
future with years to go, then, the current user population
is still a small fraction of what it will be two years from
now.  If we make a preemptive surgery (even to break
existing batch files) and eliminate unsymmetrical assignment
of command switches, we all come ahead.

The re-assignment of the switch letter is a very sticky issue.


Related to the GUI-based quick-and-dirty version, here's even
simpler solution for the current problem of finding the right
switch for XXCOPY.

   -------------------------------------------------------------
    I believe it was Sensei RIck who introduced to me the AutoIT
    freeware.  What impressed me most was not the program itself.
    But, I really liked the HTML-based Help which is well done.
    I don't know why I like that help so much because it was not
    the first time I saw an HTML- help.  Something subtle about
    that help which gave me a very positive experience.  So, I'm
    going to spend some time to have our version of good HTML-help
    not just the .HTM doc that I put together.  The two-pane
    compiled .CHM file that is so much better to find the right
    info.
   ---------------------------------------------------------------

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

At 2002-02-01 11:25, Bob Weir wrote:
>I hope that the pro licence for "one" computer does/will permit use for file
>transfer between a portable and a second machine but exclude any other
>simultaneous use of the software.
>
>I may be drummed out for this, but I think the FW version contains more than
>the great majority of potential users need or could use without help.  For
>the pro version, the 60 day trial is surely enough to convince any potential
>purchaser of its value.
>
>Most of the requirements for W9x "cloners" would be met with a reduced
>version of XXCOPY containing only the following switches: -
>
>/CLONE
>/EZCOPY ( this is /CLONE incorporating Z0 instead of ZY)
>/RMDIR
>/SP
>/L
>
>Such a FW version of XXCOPY listing only these five switches (although
>presumably also containing their component switches) would need simpler,
>long life editions of  XXFW "User manual" and "FAQ" bulletins than does the
>pro version of XXCOPY.  The FW version should then generate little, if any,
>need for support from Kan or this group.
>
>Replacing the current FW with this subset for use on a single, personally
>owned, stand alone, machine should help to separate the mass market from the
>specialist niche which Kan needs for ongoing revenue.
>
>P.S.  How about EZCOPY in all versions?  It's easier than
>/KS/H/E/R/Q/Y/BI/Z0/ZE and further reduces any potential confusion arising
>from the use of /CLONE/Z0
>
>regards,
>
>Bob Weir

> * * * * * * * * * * * *
>
> By the way, we have all seen enough of your martial
> art links
> at the end of your messages.  According to the good
> old netiquette,
> a signature section should be up to four lines
> (preferably three).
> But in here, we do not really appreciate any of
> them.

Naturally my first reaction is bite me, but then I
remembered reading my anger management book. The sig
files are automatic and help feed my family. I have
the option of clicking off use signature which I will
try to remember to do

Rick

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com

> By the way, a number of people wanted to have XXCOPY follow
some sorted order in file operations, notably, alphabetic,
by-size, by-date, by-filename-length.  The good news is
we are working toward that direction. <

Thanks!

> But we are still supporting XXCOPY16.

Are your paying customers paying for XXCOPY32 functionality or XXCOPY16?
Remember, Microsoft has abandoned support for DOS / Windows
3.x. There should be no shame in saying that future improvements
will be made to XXCOPY32 only. Chances are, the new features would
not even be used in DOS. So many things are inaccessible there, not
the least of which is CD-R or CD-RW support and Long FileNames.

Note that I'm not suggesting you discontinue XXCOPY16 support, I'm
suggesting not requiring that every new feature be able to be
included in FAT16 / 640k. I have 512MB of memory, so it hurts when
I can't do stuff for lack of memory!

By all means, if there's a groundswell of *paying* DOS users out there,
go with the flow. But I would bet if you polled your registered
customers for their needs and OS's, DOS/Win 3.x would not be as
popular by far as FAT32 and NTFS.

I know that everyone occasionally dips into DOS / FAT16 to do the
stuff you can't do elsewhere, but without LFN's, is there much
you'd really want to do with XXCOPY? Otherwise, when was the last
time you ran Win 3.X?

> All my systems have two hard drives so I never have to back up to
tape or another server. <

That's fine... until someone steals your workstation (with both
drives in it) or a voltage spike destroys both hard drives, or...
you name it. Off-site backups are better security.

>regarding quantity limitations, kan, how would you deal with this
>situation: the total file quantity to be copied is 800mb and the
>available space is 500mb. at the 350mb point of the copy process, the
>next file to be copied is a large single 300mb file. this
>triggers 'out of space'. will you stop or merely skip this file and
>continue on with the copy session? if you continue, then the
>principle of skipping files that are to large for the ever
>diminishing hole continues until the very last cluster is taken.

Sorting the list of files from largest to smallest and simply skipping
the ones that don't fit is about as optimal as anyone should expect.
No exponential box fitting problems, just an n log n mergesort on size, followed
by a sequential copy attempt on all files in the list.

Determining which files have been copied and which have not either
means setting some attribute (either archive or, say read-only),
or else keeping a temporary file list someone in memory or temp space. Maybe
XXCOPY could require temp file space (space on a drive
pointed to by environment var TEMP) before using these advanced options.

P.S. Kan, consider waiting 12-24 hours before responding to messages
unless they are something you clearly can only answer or we're not
doing it right. I think there's plenty of people that will help if you
give them a chance, but if you do the work anyway before they can
respond, then they're not going to even bother.

Sorry everyone;

I woke up this morning almost calling in sick and let
my illness show not only by misspelling stuff like
this but by yelling at you all

The sig check list is bleow my view on the monitor but
i will try to remember
Rick

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com

Sorting itself can be done with a dir list parameters
on a directory by directory basis but not smallest to
largest if subdirs are involved

Rick
>
>
> ------------------------ Yahoo! Groups Sponsor
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com

>
> That's fine... until someone steals your workstation
> (with both
> drives in it) or a voltage spike destroys both hard
> drives, or...
> you name it. Off-site backups are better security.

or you ask your exgirlfriend to mail you back your cpu
and it comes back with both harddrives unreadable
(true story)

Rick

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com

Glad you liked the autoit help

There was too much info for me to copy part of it but
the readers will get the idea from the letter.

One possibity of a GUI that would also save a lot of
questions in the forum possibly might be to create a
gui I've seen for batch file generating programs

You tell it what you want, it creates the switches,
but you still utilize it as a command line. After
seeing the commands and how they relate eventually
users are weened away from the GUI

Rick

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com

Although a simple GUI would be a help for me, I doubt if it would be a commercial success. My LAN administrator, for example, is young and refuses to use DOS unless absolutely necessary. He wants a visual interface that incorporates an explorer view of the directories and files and will settle for nothing less. He has used BackupExec and ArcServe and expects to be able to check boxes next to a directory and copy the directory and all subdirectories.

This approach, of course, is only possible if you strip off most of the flexibility and power of Xxcopy and make it into a rigid backup program. Otherwise, you would need thirty check boxes next to each directory for all of the options. Is there a market for such a backup program? I think that there is because the 'big boys' refuse to backup to removable disk drives since the profit is in managing the tape sets. However, it is a market that the 'big boys' can destroy anytime they want by allowing their products to backup to disk.

The simple approach of check boxes to apply to the entire job is possible, but too simplistic for most commercial installations. If you allowed hand fixes to the resulting code (instead of hiding it) you will, again, scare off most users under forty.

What a quandary

-Gabe Fineman

> > But we are still supporting XXCOPY16.
>
> Are your paying customers paying for XXCOPY32 functionality or
XXCOPY16? Remember, Microsoft has abandoned support for DOS / Windows
> 3.x. There should be no shame in saying that future improvements
> will be made to XXCOPY32 only. Chances are, the new features would
> not even be used in DOS. So many things are inaccessible there, not
> the least of which is CD-R or CD-RW support and Long FileNames.

We are one of the customers requring XXCOPY16.  Not only do we use
WinXP and WinME machines, we also use Win98, Win95, and DOS
machines; I don't think there are any more Win3.1s around.  Several
of our older polishing machines and profilometers
are DOS machines.  It is easy to say, "Well, gosh, just replace them"
(which, personally, I would LOVE), but in practice it just isn't
going to happen anytime soon. Other machines and workstations get
priority, while the older machines are still in use and have to keep
up with hardware and software changes.

My batch files test the DOS window to determine which program is
appropriate: XXCOPY or XXCOPY16.  The long filenames are not a
problem unless the file is required by an older machine.  We have
trained our programmers to keep names of executables to 8.3.

Kan's software is worth every cent.

Melissa Evans
ASML Optics, LLC
Richmond, California

Nothing is perfect!  With W9x, a (second) removable hard drive which is
stored elsewhere, plugged in for the daily incrementing and decrementing
with /CLONE and immediately removed is quite good.(multiple partitions need
a re-start).  This scheme has the advantage that it does not need a W9x +
link or backup software re-installation on the first disk to get going after
disk failure or corruption, and, with luck, SMART may have an given early
warning.

Bob Weir

Kan,
         what a dilemma!  If your proposed GUI gives some priority to the
presentation of the multiswitches /SYNC (= /CLONE /Z0), /CLONE and /RMDIR it
may assist those potential users who only read the first few lines in any
text.  As long as this does not obscure the rest of the content, it may even
help with your underlying objective by demonstrating the unrestricted use of
multiswitches early on in any trials by a more competent user.

Regards,

Bob Weir

Hi Kan,

I tried with the latest freeware version from the web. I just tried
cp -a orgdir destdir under Cygwin and got correct results in all
cases of file system types. So I think it's probably a bug of xxcopy.

Duranto.


--- In xxcopy@y..., Kan Yabumoto <tech@x> wrote:
>
> Duranto:
>
> Thank you for your report.  We will look into it.  Can you guess
what
> is involved in the case of "partial" success in some of the cases
you
> reported?  (We will look into it but if you already have some
> observation there, it will help us in going directly at the problem
> especially when the incidents are rare).
>
> I assume you are talking about the latest beta release.
> (Since we will be dealing with this problem as a debugging session,
> we will start talking with new beta test versions from now on).
>
> Kan Yabumoto
> ================================================
=====================
> At 2002-01-17 01:52, you wrote:
> >Hi Kan,
> >
> >I've tried it on a w2k pro pc for both fat32 and ntfs volumes. It
does
> >preserve directory timestamps correctly when I copy from fat32 ->
fat32
> >and ntfs -> fat32. But it doesn't do correctly when I copy from
fat32 ->
> >ntfs, ntfs -> ntfs. Copying from fat32 -> ntfs preserved only
_some_
> >directories' timestamps. Copying from ntfs -> ntfs doesn't
preserve any
> >directories' timestamps at all, i.e., current time is used.
> >
> >Duranto.

>We are one of the customers requring XXCOPY16.  Not only do we use
>WinXP and WinME machines, we also use Win98, Win95, and DOS
>machines; I don't think there are any more Win3.1s around.

Great. Now as one of these customers, do you really require any further
development?

It sounds like what you have works great for what you need. Aside from
fixing bugs, it does not really sound like you need anything else. If this
is true, then my point is that you shouldn't care if new development makes
features only for use on Win32 environments. The software exists and it
works well for what you want it to do.

What I want it to do can't be easily done in a Win16/DOS environment, but
that's not important for me. I think there's room to keep both camps happy.

Jeseph:

After all these 200+ switches, any new feature we
add will be appreciated by only a small minority.

In most cases other than the LFN-related features,
if a feature is useful to Win32 users, it is usually
equally useful to DOS users.

If we go by the size of the market and the user
composition only, you are right.  DOS users are a
minority.

But, for us, the stake is high.  We want to claim
that our product is better than competing products.
We want XXCOPY and XXCOPY16 to be better not just
in one or two categories, but in whichever angle
you compare.  We want everybody to agree on that.
So, we just can't settle for mediocrity.

Besides, we don't want to give Bill Gates excuse to
bargain the price of our company when the time comes :-)

Kan Yabumoto
========================================================
At 2002-02-02 20:01, Joseph wrote:

> >We are one of the customers requring XXCOPY16.  Not only do we use
> >WinXP and WinME machines, we also use Win98, Win95, and DOS
> >machines; I don't think there are any more Win3.1s around.
>
>Great. Now as one of these customers, do you really require any further
>development?
>
>It sounds like what you have works great for what you need. Aside from
>fixing bugs, it does not really sound like you need anything else. If this
>is true, then my point is that you shouldn't care if new development makes
>features only for use on Win32 environments. The software exists and it
>works well for what you want it to do.
>
>What I want it to do can't be easily done in a Win16/DOS environment, but
>that's not important for me. I think there's room to keep both camps happy.

> In most cases other than the LFN-related features, if a feature is
useful to Win32 users, it is usually equally useful to DOS users. <

Is this really true? Wouldn't enhancements be more useful to the larger
market share?

>If we go by the size of the market and the user composition only, you are
>right.  DOS users are a minority.

You've concentrated before more on who will pay the most for what feature,
almost to the point of being mercenary. ("We'll develop that feature when
someone offers enough money for us to develop it.") Why are you working so
hard for this minority? Are you getting new licensing from DOS/Win16
clients these days?

The scenario from the gentleman that replied is that they have historical
machines that keep chugging away. They don't want to do anything new
(correct me if I'm wrong here), but they want to keep doing what they are
doing, not necessarily change what they are doing.

  > So, we just can't settle for mediocrity.

So, you're saying that if you don't continue to develop new features for a
discontinued operating system, that you will be perceived as mediocre? What
about not developing new features for current OS's, because they are hard
or impossible to code for DOS/Win16? Won't that lead to mediocrity as well?

>Besides, we don't want to give Bill Gates excuse to bargain the price of
>our company when the time comes :-)

I doubt that BG would value your support of a discontinued operating system
as anything but a liability. If Microsoft bought you, wouldn't the first
thing they'd have to do is state that as you are now part of Microsoft, you
can no longer support products that they've discontinued? I'd hardly expect
they'd feel this is added value.

Work on XXCOPY as if the only income you're going to see is from new
registrations. Figure out the demographics of your target market and focus
your development there on features that they'll want to use.

Jeseph:

Thank you for your advice.

Our mercenary mentality is simply for survival (in the short term).
Yes, we work on a feature which is demanded by a potential big
customer who would pay us $1000 or more.  But, that shift of
priority is only on which feature to work next.  Once we start
working on a feature, we always go extra miles to make it right.
So, the priority shift does not compromise our long term goal
of making XXCOPY to be the best tool.  We have to go one feature
at a time.

It is true that pure DOS-only users are becoming smaller and
smaller.  But in a sense XXCOPY's continued support for DOS
is not just for the DOS-only shops.  It's for everybody who
wants to have the FAT32 compatibility.  The DOS arguments are
a little extreme but what about NT4.  I can't imagine we
abandon NT4 for another 3 or 4 years (that's a long time).
What Microsoft wishes is one thing.  What IT departments do
is quite another.  It is quite amazing the number of companies
who continue to use NT4 despite their incompatibility with
the FAT32.

Let me start an excursion to my ozone trip...

To be honest, I wish Microsoft slows down their release of
new platforms.  Sure they want to sell new things every
other year.  But, the rest of the world need not dance to
the tune.  We should all resist to the change as much as
possible.  Although I like the XP, I hope the adoption of
the XP by the industry is slow -- the slower the better for
everybody in the long run.  I think it's quite criminal that
Microsoft never reduces their OS price while all other components
are getting cheaper.  Win95 was $90 when PC were sold at
$2500.  Now, a good computers are around $1000 and they want
$200 for the XP-Pro.  The volume today is higher than 7 years
ago.  The artificially high price is a result of monopoly.
While the government and the court fail to address the
problem, the customers can resist to the change.  There is
no rush for a new thing.  Let us all take time.  I read
Bill Gates spending $25 billion dollars to save the world.
Great.  If he advocates slowing down the pace of Microsoft's
desire for constant changes, it saves a lot of trees and
resources.  Why do we have to throw away perfectly good
computers running Win95?

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

At 2002-02-03 10:57, you wrote:
>  > In most cases other than the LFN-related features, if a feature is
>useful to Win32 users, it is usually equally useful to DOS users. <
>
>Is this really true? Wouldn't enhancements be more useful to the larger
>market share?
>
> >If we go by the size of the market and the user composition only, you are
> >right.  DOS users are a minority.
>
>You've concentrated before more on who will pay the most for what feature,
>almost to the point of being mercenary. ("We'll develop that feature when
>someone offers enough money for us to develop it.") Why are you working so
>hard for this minority? Are you getting new licensing from DOS/Win16
>clients these days?
>
>The scenario from the gentleman that replied is that they have historical
>machines that keep chugging away. They don't want to do anything new
>(correct me if I'm wrong here), but they want to keep doing what they are
>doing, not necessarily change what they are doing.
>
>  > So, we just can't settle for mediocrity.
>
>So, you're saying that if you don't continue to develop new features for a
>discontinued operating system, that you will be perceived as mediocre? What
>about not developing new features for current OS's, because they are hard
>or impossible to code for DOS/Win16? Won't that lead to mediocrity as well?
>
> >Besides, we don't want to give Bill Gates excuse to bargain the price of
> >our company when the time comes :-)
>
>I doubt that BG would value your support of a discontinued operating system
>as anything but a liability. If Microsoft bought you, wouldn't the first
>thing they'd have to do is state that as you are now part of Microsoft, you
>can no longer support products that they've discontinued? I'd hardly expect
>they'd feel this is added value.
>
>Work on XXCOPY as if the only income you're going to see is from new
>registrations. Figure out the demographics of your target market and focus
>your development there on features that they'll want to use.

I would like to start using xxcopy. Would someone assist with these
questions.

Software Platforms:

NT40 server with NTFS and SRP5
WIN2000 workstation with FAT32 and SRP2
(The server is backed up once a month with GHOST2002)
The daily financial changes are backed up at the end of each day
using a batch file)

Presently using Win2000 xcopy command in a single line batch file to
copy the contents of the financial folder on the NT40 server to the
Win2000 workstation at the end of each day. The financial folder has
many subfolders amounting to about 90mb. The syntax of my present
Win2000 batch file is as follows:

xcopy E:\ADVDATA\*.* C:\BACKUP\*.* /s /e /h /f /y

E: = server location
C: = workstation

Recently I read some articles on xcopy not restoring files correctly
using long and short file names. Since I've never had to restore the
files, I thought all was well.

Question 1 - Should I use XXCOPY freeware or XXCOPYPRO?

Question 2 - What would be the correct XXCOPY syntax to place in my
daily batch file in place of the xcopy syntax given above?

Question 2 - What would be the correct XXCOPY syntax to restore the
data back onto the server?

jfife77,

1)  You should use xxcopy pro; it's meant for network copying.

2) & 3) You must read the various XXCOPY documents that Kan as provided on
the website; it's not reasonable to expect a "spoonfed" solution.

The above is not a flame but an entreaty to use the "learn to fish vs. the
give a fish" methodology to solve this problem.  XXCOPY is SO useful that
learning the switches (by reviewing the documents) will be much more
helpful than just dumping out an answer for you.

Hint: You'll find the syntax for backup (and ultimate restore) in your
example to be simpler in XXCOPY than in XCOPY !

Chaz


At 06:52 PM 2/3/2002, jfife77 shaped the electrons thusly:
>I would like to start using xxcopy. Would someone assist with these
>questions.
>
>Software Platforms:
>
>NT40 server with NTFS and SRP5
>WIN2000 workstation with FAT32 and SRP2
>(The server is backed up once a month with GHOST2002)
>The daily financial changes are backed up at the end of each day
>using a batch file)
>
>Presently using Win2000 xcopy command in a single line batch file to
>copy the contents of the financial folder on the NT40 server to the
>Win2000 workstation at the end of each day. The financial folder has
>many subfolders amounting to about 90mb. The syntax of my present
>Win2000 batch file is as follows:
>
>xcopy E:\ADVDATA\*.* C:\BACKUP\*.* /s /e /h /f /y
>
>E: = server location
>C: = workstation
>
>Recently I read some articles on xcopy not restoring files correctly
>using long and short file names. Since I've never had to restore the
>files, I thought all was well.
>
>Question 1 - Should I use XXCOPY freeware or XXCOPYPRO?
>
>Question 2 - What would be the correct XXCOPY syntax to place in my
>daily batch file in place of the xcopy syntax given above?
>
>Question 2 - What would be the correct XXCOPY syntax to restore the
>data back onto the server?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Does anyone know how I can use the /Clone option when copying a backup
made on a cd without having all the files copies be read-only? The
clone option has worked perfectly when restoring from a cd, but then I
have to go through and undo all the read-only attributes. Thanks.

On Mon, 04 Feb 2002 11:39:11 -0000, "hschwartz2002" <hschwartz@...>
wrote:

>Does anyone know how I can use the /Clone option when copying a backup
>made on a cd without having all the files copies be read-only? The
>clone option has worked perfectly when restoring from a cd, but then I
>have to go through and undo all the read-only attributes. Thanks.

I don't know if xxcopy has the ability but a dos tool present on all modern
microsoft OS installations (attrib.exe) is purpose built for it, so add
another line to your restoring batch file:

attrib drive:\target_directory\*.* -r /s

--

Regards,
Michael

>The scenario from the gentleman that replied is that they have
historical machines that keep chugging away. They don't want to do
anything new (correct me if I'm wrong here), but they want to keep
doing what they are doing, not necessarily change what they are doing.

There is plenty "new" going on. There are changes every day. I am
almost afraid to go on vacation: they steal my tools and change all
the software <g>.

If you want to pay for new computers and their integration for us,
please feel free.  I have often wondered, as a "worker bee," about
the priorities set in this place. However, we are still here after 70
years, though in another incaranation. We have gone from making
telescopes for secondary schools, to making high-tech lenses and
mirrors for the computer industry. We also have done space optics: I
once had a half-million dollars' worth of little COSTAR mirrors (for
the Hubble fix) on my bench, waiting for an ancient machine to chug
away on them.

We don't use xxcopy to back up system files. We use it to archive
data automatically, and to push the latest programs onto all kinds of
machines, again automatically. I also use it "by hand" to keep an eye
on what's going on. It is one of my favorite utilities of all time
(Kan: the boss heard about it from a radio program).

Melissa Evans
ASML Optics, LLC
Richmond, California