My freeware CLONEXX program

N

null

For cloning drive C: to D: CLONEXX version 1.1 at my web site now
includes provisions for cloning R/O, Hidden and System file and
directory attributes which may have changed since original copying.
The program features detailed cloning verification checks. The ZIP
file includes XXCOPY.EXE and the LOCATE.COM utility. So far, the
program has only been tested on my Win ME PC. It should be Win 9x
compatible at least. Not sure if will work on later Windows OS.


Art
http://www.epix.net/~artnpeg
 
B

Boomer

(e-mail address removed) wrote in
For cloning drive C: to D: CLONEXX version 1.1 at my web site now
includes provisions for cloning R/O, Hidden and System file and
directory attributes which may have changed since original copying.
The program features detailed cloning verification checks. The ZIP
file includes XXCOPY.EXE and the LOCATE.COM utility. So far, the
program has only been tested on my Win ME PC. It should be Win 9x
compatible at least. Not sure if will work on later Windows OS.


Art
http://www.epix.net/~artnpeg

Thank you, Art! :)
 
N

null

(e-mail address removed) wrote in


Thank you, Art! :)

You're welcome. I had a short exchange with Kan, the author of XXCOPY,
on a batch file n.g., and he recognizes the problem (which isn't
terribly serious I don't think) when using XXCOPY for routine backup.
He used the term "super cloner" when considering a mod to his program
which would insure attributes at the destination are the same as the
source. In doing some work along these lines, I found that the cost in
backup time is quite significant only if there is a concern for making
sure all archive bits jive. So I didn't include that since I don't
think it's worth taking the added backup time. I wound up with a "not
quite super" cloner :)

I dunno whether or not Kan will ever create the "super cloner".
Meanwhile, I'm satisfied with using my own creation and I hope others
find it useful as well.


Art
http://www.epix.net/~artnpeg
 
B

Bjorn Simonsen

For cloning drive C: to D: CLONEXX version 1.1 at my web site now
includes provisions for cloning R/O, Hidden and System file and
directory attributes which may have changed since original copying.
The program features detailed cloning verification checks. The ZIP
file includes XXCOPY.EXE and the LOCATE.COM utility.

Just downloaded your clonexx.zip archive. Nice initative/solution.

About LOCATE.COM, FYI you are distributing an older version.

Your version: v1.29 Oct 08 2000
Most recent: v1.30 Sept 08 2002

Get the latest from: <http://www.highfiber.com/~raster/freeware.htm>

See <Locate.s> file in zip archive for changes/fixes implemented in
version 1.29a, 1.29b and 1.30.

Btw: It seems you are not honoring the authors wishes re distribution.
From Locate.txt:

<copy>
You may distribute LOCATE if you like. An archive file (ZIP, LHA,
ARJ, RAR) is the preferred method, since it retains the file
attributes and date-and- time stamps, and keeps related files
together. If you distribute LOCATE.COM, please keep this file
LOCATE.TXT with it unless space is unusually limited. You may include
the source file or not, as you choose. The source is big and
ugly, and most users will have no use for it.
</copy>

Thus up to you, but it should not cost you or your users much overhead
to include the relevant txt file, or if possible - include the entire
Locate archive as part of your own archive.
So far, the program has only been tested on my Win ME PC. It
should be Win 9x compatible at least. Not sure if will work
on later Windows OS.

About compatibility, did you see my reply in
<Here is a copy:

#<copy>

I've recently added a verification check to my backup.bat file and
thought others might be interested. The use of xxcopy for routine
backup to another hard drive has been discussed here in the past. I
use the versatile locate.com by Charles Dye for verification. It also
supplies additional useful data. It can be downloaded from here:

http://www.highfiber.com/~raster/freeware.htm

Cool. I've been using Charles Dye's Locate for years, also under
Win2k. Check out its MACRO features if you haven't already! - very
handy indeed! Limited LFN support, but still very useful File Finder
this one (and batch builder using the macro features:).
See said:
Info produced by locate.com using the /S (summary) switch includes:

Notice that your use of it assumes you have *not* disabled 8+3 file
naming in Windows (see http://www.jsiinc.com/suba/tip0000/rh0026.htm)
- as Locate only search for 8+3 names - while it can display LFNs when
the /L switch is invoked. See about the /L switch in Locate doc or on
screen help.

#</copy>

All the best,
Bjorn Simonsen
 
N

null

Just downloaded your clonexx.zip archive. Nice initative/solution.
Thanks!

About LOCATE.COM, FYI you are distributing an older version.

Your version: v1.29 Oct 08 2000
Most recent: v1.30 Sept 08 2002

Oh oh. Good you caught that. I found I had an older version still left
in a dir on my PC and sure enough that's the one that got zipped and
uploaded. I just fixed that.
Get the latest from: <http://www.highfiber.com/~raster/freeware.htm>

See <Locate.s> file in zip archive for changes/fixes implemented in
version 1.29a, 1.29b and 1.30.

Btw: It seems you are not honoring the authors wishes re distribution.
From Locate.txt:

<copy>
You may distribute LOCATE if you like. An archive file (ZIP, LHA,
ARJ, RAR) is the preferred method, since it retains the file
attributes and date-and- time stamps, and keeps related files
together. If you distribute LOCATE.COM, please keep this file
LOCATE.TXT with it unless space is unusually limited. You may include
the source file or not, as you choose. The source is big and
ugly, and most users will have no use for it.
</copy>

Thus up to you, but it should not cost you or your users much overhead
to include the relevant txt file, or if possible - include the entire
Locate archive as part of your own archive.

I had thought about that and decided that under the circumstances
where I'm not distributing for use of locate.com except as a shelled
utility in my program it didn't apply. Anyone interested in locate.com
has the url available on my Info page in the program.
About compatibility, did you see my reply in
<Here is a copy:

Yes, I recall seeing that.
#<copy>



Cool. I've been using Charles Dye's Locate for years, also under
Win2k. Check out its MACRO features if you haven't already! - very
handy indeed! Limited LFN support, but still very useful File Finder
this one (and batch builder using the macro features:).


Notice that your use of it assumes you have *not* disabled 8+3 file
naming in Windows (see http://www.jsiinc.com/suba/tip0000/rh0026.htm)
- as Locate only search for 8+3 names - while it can display LFNs when
the /L switch is invoked. See about the /L switch in Locate doc or on
screen help.

#</copy>

But I'm not displaying file names so there's no need for the /L
switch. Here's the appropriate cut from Charles's locate.txt:
***********************************************************************
/L Display Windows 95 Long filenames. This switch will only work
under
an operating system which provides the long-name API. It will
work
in a DOS box under Windows 95, but not in Win95 DOS mode (MS-DOS
7.x.)
It will work with DR-DOS, but only if you have Caldera's
long-filename TSR
installed.

This switch only affects the display! LOCATE still searches for
files
using the old, 8.3 filenames. If you want to search for a specific
long
filename, I recommend that you type only the first five letters,
followed
by an asterisk: LOCATE BLUER* /L to find a file named "Blue
Rivets.bmp".
(This file has a short filename of BLUERI~1.BMP, so BLUER* will
match it.)
To find all the short "aliases" which refer to non-8.3 filenames,
you can
use a filespec like *~*
***********************************************************
You see, it only affects the display and not the functionality.

Thanks for the heads up.


Art
http://www.epix.net/~artnpeg
 
B

Bjorn Simonsen

I had thought about that and decided that under the circumstances
where I'm not distributing for use of locate.com except as a shelled
utility in my program it didn't apply. Anyone interested in locate.com
has the url available on my Info page in the program.

I understand your reasoning, but still...including the relevant text
file will not in any way affect the operation of your program and at
the same time it honors the authors wish. Personally I think it is
simply bad practice to distribute files without proper attribution of
authorship and origin in a distribution archive like yours when these
are known. hat you offer (clues to) such info on your webpage is more
or less irrelevant here. Consider that your file may lead a life on is
own, by being passed from one user/site to another - without proper
mentioning of distribution site/source (URL/you). Documentation inside
the archive, both for the 3.party programs you have included - and a
separate file (like a file_id.diz or readme.txt) with your own info
about the distro and your own program, with URL to your homepage,
should be in place to help anyone receiving it trace and acknowledge
the appropriate sources. Further - as a user - if I didn't know the
potential of Locate from before - I would certainly appreciate a copy
of the documentation as part of your distribution, as a potential "eye
opener" for what (else) Locate can do. Without this documentation I
might otherwise miss out on a very good program. That this does not
affect the operation of your program/your use of Locate is another
issue. Same goes for xxcopy of course.
But I'm not displaying file names so there's no need for the /L
switch. Here's the appropriate cut from Charles's locate.txt:

You missed my point.

You see, it only affects the display and not the functionality.

Read the above notice from me again. It is a warning: Locate will only
search for 8+3 names, as explained under the /L switch. Your program
makes use of Locate for "verification" of a copy operation. If a user
have turned off 8+3 naming in Windows, in other words uses LFN only,
your test of successful copy by use of Locate will always fail. Thus:
A proper warning from you that Windows 8+3 file naming must not be
disabled for your solution to work would be in place.

All the best,
Bjorn Simonsen
 
N

null

I understand your reasoning, but still...including the relevant text
file will not in any way affect the operation of your program and at
the same time it honors the authors wish. Personally I think it is
simply bad practice to distribute files without proper attribution of
authorship and origin in a distribution archive like yours when these
are known. hat you offer (clues to) such info on your webpage is more
or less irrelevant here.

Not just my web page. Links to both xxcopy and locate.com sources are
included in my program itself. Did you look at the Info pages?
Consider that your file may lead a life on is
own, by being passed from one user/site to another - without proper
mentioning of distribution site/source (URL/you).

That's why I included the urls in the program itself.
Documentation inside
the archive, both for the 3.party programs you have included - and a
separate file (like a file_id.diz or readme.txt) with your own info
about the distro and your own program, with URL to your homepage,
should be in place to help anyone receiving it trace and acknowledge
the appropriate sources.

Maybe for my program but I don't see it for the others. Way too much
clutter. And to include Charles's ASM source, for example, would
increase the size of the d/l considerably.
Further - as a user - if I didn't know the
potential of Locate from before - I would certainly appreciate a copy
of the documentation as part of your distribution, as a potential "eye
opener" for what (else) Locate can do. Without this documentation I
might otherwise miss out on a very good program. That this does not
affect the operation of your program/your use of Locate is another
issue. Same goes for xxcopy of course.

Again, they can download it from the source. I guess we'll just have
to agree to disagree about this, though I may add something or other
additional. I'll have to think about it further.
You missed my point.



Read the above notice from me again. It is a warning: Locate will only
search for 8+3 names, as explained under the /L switch. Your program
makes use of Locate for "verification" of a copy operation. If a user
have turned off 8+3 naming in Windows, in other words uses LFN only,
your test of successful copy by use of Locate will always fail. Thus:
A proper warning from you that Windows 8+3 file naming must not be
disabled for your solution to work would be in place.

Ah! very good point. I did miss it :) Thanks.


Art
http://www.epix.net/~artnpeg
 
S

Sietse Fliege

Bjorn said:
Same goes for xxcopy of course.

From its readme.txt :

"With the freeware license, you may give your friends a copy of the
XXCOPY Freeware, as long as the package is not altered and remains
as a whole."
 
N

null

I understand your reasoning, but still...including the relevant text
file will not in any way affect the operation of your program and at
the same time it honors the authors wish.

I'm considering the following:

1. Offer only my clonexx program for download. Suggest that it be
extracted to c:\clonexx
2. Explain that the program requires the two additional programs and
give the download urls.
3. Suggest that locate.zip be extracted to c:\locate
4. Suggest the xxcopy.zip be extracted to c:\xxcopy
5. Suggest that only locate.com be copied to c:\clonexx directory from
c:\locate
6. Suggest that only xxcopy.exe be copied to c:\clonexx directory from
c:\xxcopy

That has a slight advantage for me in that I only need be concerned
with updating my program and not the others. Far more awkward for
users though. But I still prefer this to a download and extract to a
single directory of the whole shebang. That would be very confusing
and make a messy folder. And trying to explain how to selectively
extract to various directories would also be a mess :)


Art
http://www.epix.net/~artnpeg
 
K

Kan Yabumoto

For cloning drive C: to D: CLONEXX version 1.1 at my web site now
includes provisions for cloning R/O, Hidden and System file and
directory attributes which may have changed since original copying.
The program features detailed cloning verification checks. The ZIP
file includes XXCOPY.EXE and the LOCATE.COM utility. So far, the
program has only been tested on my Win ME PC. It should be Win 9x
compatible at least. Not sure if will work on later Windows OS.
Art
http://www.epix.net/~artnpeg

=================================================================

For those who just read this thread, my first advice as the author of
the XXCOPY program (which is incorporated inside CLONEXX) is NOT to
run the CLONEXX program.

Art, I'm sorry to start my comment with this rather abrupt beginning.
I just wanted to pass my first reaction before anyone loses his
priceless files by accident. The CLONEXX.EXE program I just tested
was just unacceptably dangerous. Let me repeat out loud ----

C L O N E X X is T O O D A N G E R O U S.

Art, I appreciate your "support" in publicizing my XXCOPY program.
However, I have a few comments to make. (Since this message has
some urgency, I will post why I think it this way later).

Kan Yabumoto
The Author of XXCopy
 
K

Kan Yabumoto

A follow up to my previous message:

I feel I have to tell you why I feel strongly about this.

I came across this thread by pure accident and I had to give it
a try to see what CLONEXX is all about. So, I ran it once.
I had to abort the first run rather quickly as soon as I realized
that the XXCOPY program which was indirectly invoked by CLONEXX.EXE
was doing something which I did not want. No, I did not lose any
of my files. I have sufficient amount of backup in place.

Before getting into various issues with the redistribution of our
product, I would like to point out why I think the CLONEXX program
was not designed right. I much prefer to give my feedback on
someone else's work in a private communication, especially when it
contains things that are not all positive. But, given the fact that
I discovered the CLONEXX product in this newsgroup (this very thread),
it warrants my response in the open ---- so the general public will
know my side of the story.

Let me limit my critique on the technical aspects of the program.
I do not want to be dogmatic or want to sound arrogant. I hope
Art, and anyone else who sees my comments here will read my comments
as an honest evaluation of a product from a software engineer's
point of view.

I spent only 10 minutes or so to evaluate the CLONEXX.EXE product.
I might have missed some documentation or explanations elsewhere.
But, I pretended to behave like a "typical" web surfer who just saw
this thread which advocates an interesting and potentially useful
tool. Knowing what XXCOPY does, I did not have to read much.
So, I quickly download it and ran. Like most other users, I did not
read much of the product description (I don't think I found any
documentation file that was in the unzipped file set).

The first page on the screen of CLONEXX, there was a rudimentary
description of what to expect. It may be a sufficient warning
to most people. I hope so. But, based on my long experience
in publishing the XXCOPY product and having done tech support
for all those years, I can easily predict that some people will
lose lots of files by using the CLONEXX product if it remains in
the current form.

In the past, we heard a handful of users reported that they
accidentally lost files using XXCOPY ---- fortunately, not many.
None of them blamed us --- they blamed themselves and explained
what happened to them. We always learned what was the user's
(misguided) expectation was.

One reason why XXCOPY has so many user-prompts with various
warning messages is that we consider the safety of the user data
far more important than the convenience of experienced XXCOPY users.
Most of the warning messages that XXCOPY generates are added
one by one after hearing such unfortunate episodes (lately,
we have not heard any such accident report for a long time).

So, our current design principle in XXCOPY is that *ALL*
destructive actions in XXCOPY will generate at least one warning.
You just cannot delete (or even overwrite) a file without
confirming your wish at the user prompt. Unlike the Windows
recycle bin feature which provides the much needed "undelete"
feature, XXCOPY's delete action is final like in the Unix
environment.

The /CLONE feature is quite popular, yet, it is controversial.
I even regret that the /CLONE switch became too popular and
many people suggest its use beyond what it was designed for.
More recently, we added /BACKUP switch that is a much safer
alternative to /CLONE and I prefer advocating /BACKUP over
/CLONE especially in a short communication where it is awkward
to add a warning paragraph. Whenever I suggest the use of
/CLONE, I will add the necessary warning that it is quite
dangerous because of its built-in file-deletion function. An
accident often happens unexpectedly. Just a mistyping of one
character in the command line could be enough to wipe out the
entire volume in the worst case scenario. That is why the /CLONE
switch has multiple levels of warning messages which many users
(rightly) consider as nuisance. But, in our mind, the safety
comes before convenience.

To balance the downside of the myriad of warning prompts, XXCOPY
provides many prompt-suppressing switches. Still, we always
want every user to read the various warning messages in the
proper context and to learn the implications of a given
function before dismissing the warning. XXCOPY also provides
the /YY switch which "conveniently" suppresses nearly all warning
prompts. Naturally, adding /YY is like removing the seat belt
from a car. We suggest the use of specific combination of
prompt-suppressing switches rather than taking the easy way
by using the /YY switch without any further study of each
warning messages.

My quick analysis of the CLONEXX.EXE program revealed that
it invokes the following command as a hard-coded command:

XXCOPY C:\ D:\ /CLONE /YY

I don't think the CLONEXX users are sufficiently informed
of possible loss of files.

Even though it is not the most ideal form, I would suggest
that CLONEXX program to use the following version to do
the same thing:

XXCOPY C:\ D:\ /BACKUP

Admittedly, this command line will not remove any extra
files in the destination volume that are no longer present
in the source volume ---- which will result in an accumulation
of obsolete files which eventually fill up the destination
volume (and even become full and out of space) after its
repeated usages. Nevertheless, this is a much safer alternative
especially for first-time users.

One can always show the end user how to remove the extra
files in the destination. The deletion of the extra files
can wait. It is even sufficient that only after the end
user experiences the disk-full condition, the /CLONE variation
of the command be introduced. This way, the end user will
learn the safer /BACKUP method first, and then, the /CLONE
variation next --- the user will likely to remember what
is the difference of the two and will hopefully understand
the implication of /CLONE. And, only then, does he learn
to live with the user-prompts, and also why the prompt-
suppressor switches are desirable.

Although this stepwise introduction to the advanced features
is tedious, wordy and plain inefficient, the designer
of the software product has the responsibility to educate
the end users about the minimum safety concerns. Keeping
the end users ignorant is not a good policy even though
most users are impatient and often prefer not to know the
gory details.

I hope *ALL* third-party software developers who introduce
an XXCOPY "add-on" product understand this important
design principle and respect our wish of never having to
hear from an end user who loses a lot of files.

Kan Yabumoto
The Author of XXCopy
 
N

null

A follow up to my previous message:

I feel I have to tell you why I feel strongly about this.

I came across this thread by pure accident and I had to give it
a try to see what CLONEXX is all about. So, I ran it once.
I had to abort the first run rather quickly as soon as I realized
that the XXCOPY program which was indirectly invoked by CLONEXX.EXE
was doing something which I did not want. No, I did not lose any
of my files. I have sufficient amount of backup in place.

Before getting into various issues with the redistribution of our
product, I would like to point out why I think the CLONEXX program
was not designed right. I much prefer to give my feedback on
someone else's work in a private communication, especially when it
contains things that are not all positive. But, given the fact that
I discovered the CLONEXX product in this newsgroup (this very thread),
it warrants my response in the open ---- so the general public will
know my side of the story.

Let me limit my critique on the technical aspects of the program.
I do not want to be dogmatic or want to sound arrogant. I hope
Art, and anyone else who sees my comments here will read my comments
as an honest evaluation of a product from a software engineer's
point of view.

I spent only 10 minutes or so to evaluate the CLONEXX.EXE product.
I might have missed some documentation or explanations elsewhere.
But, I pretended to behave like a "typical" web surfer who just saw
this thread which advocates an interesting and potentially useful
tool. Knowing what XXCOPY does, I did not have to read much.
So, I quickly download it and ran. Like most other users, I did not
read much of the product description (I don't think I found any
documentation file that was in the unzipped file set).

The first page on the screen of CLONEXX, there was a rudimentary
description of what to expect. It may be a sufficient warning
to most people. I hope so. But, based on my long experience
in publishing the XXCOPY product and having done tech support
for all those years, I can easily predict that some people will
lose lots of files by using the CLONEXX product if it remains in
the current form.

In the past, we heard a handful of users reported that they
accidentally lost files using XXCOPY ---- fortunately, not many.
None of them blamed us --- they blamed themselves and explained
what happened to them. We always learned what was the user's
(misguided) expectation was.

One reason why XXCOPY has so many user-prompts with various
warning messages is that we consider the safety of the user data
far more important than the convenience of experienced XXCOPY users.
Most of the warning messages that XXCOPY generates are added
one by one after hearing such unfortunate episodes (lately,
we have not heard any such accident report for a long time).

So, our current design principle in XXCOPY is that *ALL*
destructive actions in XXCOPY will generate at least one warning.
You just cannot delete (or even overwrite) a file without
confirming your wish at the user prompt. Unlike the Windows
recycle bin feature which provides the much needed "undelete"
feature, XXCOPY's delete action is final like in the Unix
environment.

The /CLONE feature is quite popular, yet, it is controversial.
I even regret that the /CLONE switch became too popular and
many people suggest its use beyond what it was designed for.
More recently, we added /BACKUP switch that is a much safer
alternative to /CLONE and I prefer advocating /BACKUP over
/CLONE especially in a short communication where it is awkward
to add a warning paragraph. Whenever I suggest the use of
/CLONE, I will add the necessary warning that it is quite
dangerous because of its built-in file-deletion function. An
accident often happens unexpectedly. Just a mistyping of one
character in the command line could be enough to wipe out the
entire volume in the worst case scenario. That is why the /CLONE
switch has multiple levels of warning messages which many users
(rightly) consider as nuisance. But, in our mind, the safety
comes before convenience.

To balance the downside of the myriad of warning prompts, XXCOPY
provides many prompt-suppressing switches. Still, we always
want every user to read the various warning messages in the
proper context and to learn the implications of a given
function before dismissing the warning. XXCOPY also provides
the /YY switch which "conveniently" suppresses nearly all warning
prompts. Naturally, adding /YY is like removing the seat belt
from a car. We suggest the use of specific combination of
prompt-suppressing switches rather than taking the easy way
by using the /YY switch without any further study of each
warning messages.

My quick analysis of the CLONEXX.EXE program revealed that
it invokes the following command as a hard-coded command:

XXCOPY C:\ D:\ /CLONE /YY

I don't think the CLONEXX users are sufficiently informed
of possible loss of files.

Even though it is not the most ideal form, I would suggest
that CLONEXX program to use the following version to do
the same thing:

XXCOPY C:\ D:\ /BACKUP

Admittedly, this command line will not remove any extra
files in the destination volume that are no longer present
in the source volume ---- which will result in an accumulation
of obsolete files which eventually fill up the destination
volume (and even become full and out of space) after its
repeated usages. Nevertheless, this is a much safer alternative
especially for first-time users.

One can always show the end user how to remove the extra
files in the destination. The deletion of the extra files
can wait. It is even sufficient that only after the end
user experiences the disk-full condition, the /CLONE variation
of the command be introduced. This way, the end user will
learn the safer /BACKUP method first, and then, the /CLONE
variation next --- the user will likely to remember what
is the difference of the two and will hopefully understand
the implication of /CLONE. And, only then, does he learn
to live with the user-prompts, and also why the prompt-
suppressor switches are desirable.

Although this stepwise introduction to the advanced features
is tedious, wordy and plain inefficient, the designer
of the software product has the responsibility to educate
the end users about the minimum safety concerns. Keeping
the end users ignorant is not a good policy even though
most users are impatient and often prefer not to know the
gory details.

I hope *ALL* third-party software developers who introduce
an XXCOPY "add-on" product understand this important
design principle and respect our wish of never having to
hear from an end user who loses a lot of files.

Kan Yabumoto
The Author of XXCopy

Kan, I understand and appreciate your concerns. I've withdrawn
clonexx. It's no longer available for download.

As to your finding out about clonexx by accident, you will recall that
we did discuss the "super cloner", as you put it, on alt.comp.batch. I
never made an attempt to engage you further (via email) since I didn't
want to bother you any more with it. The subject of dangers never
arose.

You notice there have been discussions in this thread concerning the
following of freeware redistribution wishes of authors such as
yourself and Charles Dye. I had considered various ways of handling
this. I want and wanted to avoid creating an unnecessarily large
download, a cluttered directory, and other inconveniences for users.
So I included a Info page within the clonexx.exe program itself which
has links to your web sites (and other info). Perhaps you'd like to
offer your comments and ideas concerning how you'd like to see this
handled in situations where several programs are involved.


Art
http://www.epix.net/~artnpeg
 
B

Bjorn Simonsen

I want and wanted to avoid creating an unnecessarily large
download, a cluttered directory, and other inconveniences for users.
So I included a Info page within the clonexx.exe program itself which
has links to your web sites (and other info).

From a user-perspective: I understand your motivation. But I think
your approach is bad - for one simple reason that is perhaps best
explain by a question: Say you receive or download a distribution
archive containing some exe files. Would you not like to know stuff
like; from where does these files originate, what do these files do
and who made them, what are their terms of use (like shareware or
freeware) - *before* you install them? See what I mean?

All the best,
Bjorn Simonsen
 
N

null

From a user-perspective: I understand your motivation. But I think
your approach is bad - for one simple reason that is perhaps best
explain by a question: Say you receive or download a distribution
archive containing some exe files. Would you not like to know stuff
like; from where does these files originate, what do these files do
and who made them, what are their terms of use (like shareware or
freeware) - *before* you install them? See what I mean?

There is no installation involved. You run my program, look at the
info page (as I've mentioned at least twice now) and there's the urls.
No problem that I can see. You say it's bad and I say it's far better
than the alternatives. So why don't you just drop the issue?


Art
http://www.epix.net/~artnpeg
 
B

Bjorn Simonsen

There is no installation involved. You run my program, look at the
info page (as I've mentioned at least twice now) and there's the urls.

I used "install" in my "say if" question to you. But anyway, install
or run, the principle is the same. One needs to execute a program to
get to the info - about the program it self and the 3.party programs
included in your distro.
No problem that I can see. You say it's bad and I say
it's far better than the alternatives.

Are you sure you covered all alternatives? What is bad about your
approach is clearly the idea that users will have to execute the
program to get to said information, info one may want to look up prior
to running anything at all in the first place. Is this so hard to
understand? Satisfying such a normal demand could initially have been
done very simple in this case - for example and as a bare minimum - by
copying your Clonexx info page to a text file and add this to the
distribution archive. (although this approach alone would not have
honored the said program licenses, but ... end of story ...since you
have since chosen to remove the project.)
So why don't you just drop the issue?

??? ... well- I guess I will now.

All the best,
Bjorn Simonsen
 
N

null

I used "install" in my "say if" question to you. But anyway, install
or run, the principle is the same. One needs to execute a program to
get to the info - about the program it self and the 3.party programs
included in your distro.


Are you sure you covered all alternatives? What is bad about your
approach is clearly the idea that users will have to execute the
program to get to said information, info one may want to look up prior
to running anything at all in the first place. Is this so hard to
understand? Satisfying such a normal demand could initially have been
done very simple in this case - for example and as a bare minimum - by
copying your Clonexx info page to a text file and add this to the
distribution archive. (although this approach alone would not have
honored the said program licenses, but ... end of story ...since you
have since chosen to remove the project.)


??? ... well- I guess I will now.

Actually, I do plan to include a text file when I next offer the
program .... maybe today or tomorrow. Hope that compromise makes your
day :)


Art
http://www.epix.net/~artnpeg
 
N

null

For cloning drive C: to D: CLONEXX version 1.1 at my web site now
includes provisions for cloning R/O, Hidden and System file and
directory attributes which may have changed since original copying.
The program features detailed cloning verification checks. The ZIP
file includes XXCOPY.EXE and the LOCATE.COM utility. So far, the
program has only been tested on my Win ME PC. It should be Win 9x
compatible at least. Not sure if will work on later Windows OS.

Version 1.2 is now up at my web site. It now presents suitable dire
warning messages on the start screen. Hopefully, Yan will have a
milder heart attack this time :)


Art
http://www.epix.net/~artnpeg
 
K

Kan Yabumoto

On 10 Nov 2003 00:34:11 -0800, (e-mail address removed) (Kan Yabumoto) wrote:

Kan, I understand and appreciate your concerns. I've withdrawn
clonexx. It's no longer available for download.

As to your finding out about clonexx by accident, you will recall that
we did discuss the "super cloner", as you put it, on alt.comp.batch. I
never made an attempt to engage you further (via email) since I didn't
want to bother you any more with it. The subject of dangers never
arose.

You notice there have been discussions in this thread concerning the
following of freeware redistribution wishes of authors such as
yourself and Charles Dye. I had considered various ways of handling
this. I want and wanted to avoid creating an unnecessarily large
download, a cluttered directory, and other inconveniences for users.
So I included a Info page within the clonexx.exe program itself which
has links to your web sites (and other info). Perhaps you'd like to
offer your comments and ideas concerning how you'd like to see this
handled in situations where several programs are involved.

Art

Art,

I was not totally against the idea of your program working in conjunction
with XXCOPY. I was simply pointing out the need for some additional
warning which I believe is absolutely essential when you publish
some program that has a potential for a huge disaster. Although
it is a very small chance, my experience tells me someone would get
burned. So, I encourage you to make a revised version which
will provide sufficient info as to what the program does and also
what is the worst case scenario. And, the warning must be
presented in *ALL* cases, not just a small print at some corner of
your web site. If you followed *ALL* of my writing in various
newsgroups and also at the XXCOPY discussion group (the XXCOPY
main tech support forum), you will find that I became increasingly
reluctant to even mention the /YY switch (and also the use of
/CLONE --- I now advocate /BACKUP unless /CLONE is absolutely
necessary). So, when I see a program like yours that hard-codes
the scary combination -- /CLONE/YY, my reaction is "boisterous".

In my opinion, if your freeware package helps 1000 users and
make them happy and at the same time just one user who
misunderstands something and loses all his files in D: drive,
then, I will call your effort a failure. I think *ALL*
software publishers (including nice guys out there who have
a genuine "sharing" spirit) have a responsibility to do the
best they can to protect user's precious files from an
accidental loss.

---------

Just another point I wanted to make was that your original
way of packaging (just the three files without any accompanying
text file) the product and the very limited amount of supporting
documents need improvements. As we state in our XXCOPY freeware
package (on our web site and in the accompanying README.DOC),
we would like everyone to honor our wish ----

-------------------------------------------------------
With the freeware license, you may give your friends
a copy of the XXCOPY Freeware, as long as the package
is not altered and remains as a whole.
-------------------------------------------------------

This will eliminate possible confusion as to who owns what
and who is responsible for what. We are open minded and
we often agree with other arrangements as such needs arise.
But, we are currently quite busy and don't want to put
a lot of time in coming up with special arrangements.

Kan Yabumoto
 
N

null

Art,

I was not totally against the idea of your program working in conjunction
with XXCOPY.

That's good since a new version is up at my web site as of today :)
I was simply pointing out the need for some additional
warning which I believe is absolutely essential when you publish
some program that has a potential for a huge disaster. Although
it is a very small chance, my experience tells me someone would get
burned. So, I encourage you to make a revised version which
will provide sufficient info as to what the program does and also
what is the worst case scenario. And, the warning must be
presented in *ALL* cases, not just a small print at some corner of
your web site. If you followed *ALL* of my writing in various
newsgroups and also at the XXCOPY discussion group (the XXCOPY
main tech support forum), you will find that I became increasingly
reluctant to even mention the /YY switch (and also the use of
/CLONE --- I now advocate /BACKUP unless /CLONE is absolutely
necessary). So, when I see a program like yours that hard-codes
the scary combination -- /CLONE/YY, my reaction is "boisterous".

The version now up at my web site doesn't include the /YY
Users get a chance to bail out after seeing warning messages and
deciding to go ahead. So it's sort of a "answer yes twice" thing now
with also the ability to bail out during the XXCOPY activity.
In my opinion, if your freeware package helps 1000 users and
make them happy and at the same time just one user who
misunderstands something and loses all his files in D: drive,
then, I will call your effort a failure. I think *ALL*
software publishers (including nice guys out there who have
a genuine "sharing" spirit) have a responsibility to do the
best they can to protect user's precious files from an
accidental loss.

---------

Just another point I wanted to make was that your original
way of packaging (just the three files without any accompanying
text file) the product and the very limited amount of supporting
documents need improvements. As we state in our XXCOPY freeware
package (on our web site and in the accompanying README.DOC),
we would like everyone to honor our wish ----

-------------------------------------------------------
With the freeware license, you may give your friends
a copy of the XXCOPY Freeware, as long as the package
is not altered and remains as a whole.
-------------------------------------------------------

This will eliminate possible confusion as to who owns what
and who is responsible for what. We are open minded and
we often agree with other arrangements as such needs arise.
But, we are currently quite busy and don't want to put
a lot of time in coming up with special arrangements.

Well, I hope you find the current CLONEXX package improved (and
reasonably satisfactory) in this regard since it now has a INFO.TXT
file. Users are encouraged to download the full XXCOPY and LOCATE
packages directly from their respective sources and extract them to
separate directories. I feel this is a fair way to handle the
situation for all concerned ... especially the poor user who doesn't
have to suffer a directory cluttered with files of several programs
most of which are unnecessary for the functionality of the main
program.

Thanks to all who critiqued and offered ideas and suggestions. I'd
love to hear your ideas, and suggestions for improvements, and of
problems you might encounter. Just don't ask me for a unattended batch
file version. Kan would hunt me down and shoot me :)


Art
http://www.epix.net/~artnpeg
 
W

Winston

Actually, I've been using xxcopy this way for years. I swrite a simple
autoexec.bat file named *clone* (what else?) and put it on my desktop. I USE
the *yy* so not to delay my backups.........Been working great! I've DL this
Clonexx to see if it's even easier to use......I have no problem with any
esy to use GUI and hope the YY stays in!
 

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.

Ask a Question

Similar Threads

CLONEXX 8
Cloning verification 22
[Update] SyncBack Freeware v3.2.9 5
{Freeware updates} 1
New program supporting an antivirus 7
High Quality freeware 1
[ACF] Freeware Wish List 28
My essential freeware list 35

Top