Replace Windows XP copy?

I often copy large amounts of files. Nothing is more frustrating than having
the computer copy files for an hour and then pop up an error. This means I
have to start over.

Now that Tucows has officially gone to crap I can't find any software there,
and Googling for "XP copy replacment" or "xp file copy" generate a bazillion
unrelated hits.

Are there any GOOD file copy utilities out there that I can use to replace
the XP file copy?

"Noozer" wrote in message ...
I often copy large amounts of files. Nothing is more frustrating than
having the computer copy files for an hour and then pop up an error.
This means I have to start over.

Now that Tucows has officially gone to crap I can't find any software
there, and Googling for "XP copy replacment" or "xp file copy"
generate a bazillion unrelated hits.

Are there any GOOD file copy utilities out there that I can use to
replace the XP file copy?

Yep, there are, and already included with Windows. Run "xcopy /?" for
help on using it, like the /C switch to ignore errors.

Sun, 22 Jul 2007 05:46:37 -0500 from Vanguard
:
Run "xcopy /?" for
help on using it, like the /C switch to ignore errors.

In my opinion, ignoring errors is a really good way to give yourself
a false sense of security.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/

"Stan Brown" wrote in message
t...
Sun, 22 Jul 2007 05:46:37 -0500 from Vanguard
:
Run "xcopy /?" for
help on using it, like the /C switch to ignore errors.

In my opinion, ignoring errors is a really good way to give yourself
a false sense of security.

And ignoring errors lets you continue the copying despite them. Why
lose all files just because one is bad? Yeah, the hard drive might be
going bad but why should that enforce losing ALL files? Could be the
one file is "bad" not because of a hardware defect but instead because
the file is locked. There are some utilities, like handle.exe from
SysInternals, oh.exe from Win Resource Kit, and Unlocker but most users
don't know about them because they don't realize the copy error is due
to a locked file (and don't understand what is a locked file). If you
were copying 38,000 multimedia (data) files and had to sacrifice a few
to get all the rest, would you simply decide that none of them were
salvageable because a few were not?

Run "xcopy /?" for
help on using it, like the /C switch to ignore errors.

In my opinion, ignoring errors is a really good way to give yourself
a false sense of security.

And ignoring errors lets you continue the copying despite them.

Which is still the wrong way to do it.

It shouldn't IGNORE errors. It should work around them and make you VERY
aware of what didn't work.

[Noozer] wrote-:

It shouldn't IGNORE errors. It should work around them and make you VERY
aware of what didn't work.


It will show all the errors i command prompt.

Sun, 22 Jul 2007 16:42:29 -0500 from Vanguard
:
And ignoring errors lets you continue the copying despite them. Why
lose all files just because one is bad?

Are you serious?

It's a pretty bad thing if you have a "copy" that isn't the same as
the original, but you don't know it's not the same.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/

Stan Brown wrote:
Sun, 22 Jul 2007 16:42:29 -0500 from Vanguard
:
And ignoring errors lets you continue the copying despite them. Why
lose all files just because one is bad?

Are you serious?

It's a pretty bad thing if you have a "copy" that isn't the same as
the original, but you don't know it's not the same.

The error is that the file cannot be copied. Assuming that the OP is
copying files to another directory the ignored file just won't be copied
there. The significance, of course, occurs when you assume that all
files have been copied and delete the folder with the original files.

So, yes, use "ignore errors" but be aware of the potential consequences.

Bill

"Noozer" wrote in message ...
Run "xcopy /?" for
help on using it, like the /C switch to ignore errors.

In my opinion, ignoring errors is a really good way to give yourself
a false sense of security.

And ignoring errors lets you continue the copying despite them.

Which is still the wrong way to do it.

It shouldn't IGNORE errors. It should work around them and make you
VERY aware of what didn't work.

You don't run DOS commands, do you? You haven't run the XCOPY command
and had files it couldn't copy, have you? Otherwise, you would realize
that it reports the files it cannot copy. You could edit the DOS shell
properties to up the number of buffered screen lines, like to 8000, or
you could simply redirect the stdout of XCOPY to a file, as in "xcopy
filespec {target} {logfile}".

So what is your *right* way of copying dozens, hundreds, or thousands of
files when a few will fail? Sacrifice all of them, I suppose. Yeah,
good solution, uh huh. And what is "work around them"? Could it be to
ignore and report them? Well, then you are agreeing that XCOPY is a
solution.

In fact, you don't even need to actually copy the files if all you want
to do is check if they can be read. You can run XCOPY to NULL; see
http://support.microsoft.com/kb/319137/en-us.

"Stan Brown" wrote in message
t...
Vanguard :
And ignoring errors lets you continue the copying despite them. Why
lose all files just because one is bad?

Are you serious?

It's a pretty bad thing if you have a "copy" that isn't the same as
the original, but you don't know it's not the same.

The fact that the file can NOT be copied is the error, and obviously
there was no copy made to be different than the original (unless you
include non-existence as a difference). If you want to spend the extra
cycles checking the integrity of the copies, add the /v switch. Geez,
how hard can it be for you folks to just run "xcopy /?" to actually SEE
what options are available. Duh!

You don't run DOS commands, do you?

Not if I don't have to.

You haven't run the XCOPY command and had files it couldn't copy, have you?
Otherwise, you would realize that it reports the files it cannot copy. You
could edit the DOS shell properties to up the number of buffered screen
lines, like to 8000, or you could simply redirect the stdout of XCOPY to a
file, as in "xcopy filespec {target} {logfile}".

But then it's not replacing the Windows GUI Copy or Move context menu items
is it. That's what I asked for... Something that will replace the built in
version of the commands.

So what is your *right* way of copying dozens, hundreds, or thousands of
files when a few will fail? Sacrifice all of them, I suppose. Yeah, good
solution, uh huh. And what is "work around them"? Could it be to ignore
and report them? Well, then you are agreeing that XCOPY is a solution.

It may help copy files when some may not work, but it doesn't answer my
question at all.

In fact, you don't even need to actually copy the files if all you want to
do is check if they can be read. You can run XCOPY to NULL; see
http://support.microsoft.com/kb/319137/en-us.

What I want to do is copy ? of files from one USB drive to another USB
drive. I want to keep the directory structure intact. I want to know what
files could not be copied and WHY (Path too long, CRC errors, file in use).
This will literally take HOURS to finish, so I want it to go as fast as
possible and don't want it to pause for any reason until it's done.

So... Can I go to My Computer, open the drive, CTRL-A, right-click, "XCOPY",
back to My Computer, right-click on drive #2 and "XPASTE"? When it's done
will it tell me WHY the files wouldn't copy?

It's a pretty bad thing if you have a "copy" that isn't the same as
the original, but you don't know it's not the same.

The fact that the file can NOT be copied is the error, and obviously there
was no copy made to be different than the original (unless you include
non-existence as a difference).

Duh! A copy of a file structure (multiple files, SINGLE copy operation) that
is missing a single byte of information is "not the same."

And "the fact that the file can NOT be copied" is NOT the error. It's the
result. The error could be a CRC error on the disk, file in use, path name
too long, target full, etc...

If you want to spend the extra cycles checking the integrity of the
copies, add the /v switch.

Real smart... the "/v" switch does NOT verify that the source and target are
the same. It ONLY verifies that the target is complete and readable. The
target could contain gibberish, but will pass a check using "/v" if there
are no CRC/sector errors.

Geez, how hard can it be for you folks to just run "xcopy /?" to actually
SEE what options are available. Duh!

How do you run "xcopy /?" from the desktop context menu? I'm looking for a
COPY/MOVE replacement. I'm not looking for a lesson in using DOS.

What I want to do is copy ? of files from one USB drive to another USB
drive.

This should have read "...is copy 258gig of files, comprised of 600000 files
and 47000 directories, from one USB..."

"Total Commander" will run from a USB stick. http://www.ghisler.com/

--
Mark L. Ferguson
e-mail subject line must include "QZ" or it's deleted
..
"Noozer" wrote in message
...
What I want to do is copy ? of files from one USB drive to another USB
drive.

This should have read "...is copy 258gig of files, comprised of 600000
files and 47000 directories, from one USB..."

"Noozer" wrote in message ...

You haven't run the XCOPY command and had files it couldn't copy, have
you? Otherwise, you would realize that it reports the files it cannot
copy. You could edit the DOS shell properties to up the number of
buffered screen lines, like to 8000, or you could simply redirect the
stdout of XCOPY to a file, as in "xcopy filespec {target}
{logfile}".

But then it's not replacing the Windows GUI Copy or Move context menu
items is it. That's what I asked for... Something that will replace
the built in version of the commands.

Reread your original post. You weren't asking how to make Windows
Explorer perform the copy. You stated that you had Googled around
looking for 3rd party alternatives. You never declared that they had to
be GUI utilities so dummies could use them (many seem to require a GUI
interface to specify options that can just as easily be specified in a
command line - just because that's the only user interface those users
know).

So what is your *right* way of copying dozens, hundreds, or thousands
of files when a few will fail? Sacrifice all of them, I suppose.
Yeah, good solution, uh huh. And what is "work around them"? Could
it be to ignore and report them? Well, then you are agreeing that
XCOPY is a solution.

It may help copy files when some may not work, but it doesn't answer
my question at all.

"Are there any GOOD file copy utilities out there that I can use to
replace
the XP file copy? "

My answer was that you don't have to REPLACE "the XP file copy" (which
was never defined as Windows Explorer, the 'copy' DOS command, or what).
Just use Xcopy that's already available.

In fact, you don't even need to actually copy the files if all you
want to do is check if they can be read. You can run XCOPY to NULL;
see http://support.microsoft.com/kb/319137/en-us.

What I want to do is copy ? of files from one USB drive to another USB
drive. I want to keep the directory structure intact. I want to know
what files could not be copied and WHY (Path too long, CRC errors,
file in use). This will literally take HOURS to finish, so I want it
to go as fast as possible and don't want it to pause for any reason
until it's done.

As mentioned, run:

xcopy sourcespec [targetspec] [path]logfile.txt

Walk away and when it completes you can look at the logfile.txt file
(add a path if you want it saved somewhere other than the default
directory from where you run the xcopy command in the DOS shell).
Pretty simple. Doesn't require Googling around for 3rd party
alternatives or installing anything new.

So... Can I go to My Computer, open the drive, CTRL-A, right-click,
"XCOPY", back to My Computer, right-click on drive #2 and "XPASTE"?
When it's done will it tell me WHY the files wouldn't copy?

Xcopy is a DOS command. That is, it issues its standard output to the
current shell's display (i.e., it is a console program). Xcopy is not a
GUI program with pretty windows and menu bars. Rather than having to
wade through menus to select a slew of options in a checkoff screen, you
simply run the program and specify the options using parameters. "xcopy
/?" tells you how to use the program (i.e., it even has its own help,
ta-da). If the buffer size for the DOS shell is huge then it might show
all of the output. Otherwise, and as shown, redirect stdout to a file
and then go use Notepad on the file when xcopy finishes.

I'm sure there are some GUI programs out there to do the same thing. I
don't bother looking for any since xcopy is already included with
Windows. xxcopy is a 3rd party program that has even more features but
it is also a console-mode program (a DOS program). Then there's
robocopy.exe which is included in the Windows NT Resource Kit but,
again, it is a console-mode program. I don't need GUI programs if DOS
programs do what I want, and you can redirect stdout if you want to
record the output of the program.

If you demand a 3rd party GUI application to do the copying that can
skip errors and report them then that is a different question that what
you asked. Someone else might make a suggestion for that additional
software.