File systems of USB sticks

[newtekie1]

If your drives are D(source) and E(Destination) then this is the command you should run:

robocopy D:\ E:\ /E /Z /XD "System Volume Information" /R:5 /W:5 /PURGE
pause

You should get a window that looks similar to this:

 

[Sebastian42]

That IS the code in the batch file,
The 'DOS' window shows nothing like what you say it should, in fact it is still behaving the same way even though I have removed both USBs.
I will try it again, but without the REM line.
Same result as before and NOT as YOU show.

 

[newtekie1]

At this point I'll need screenshots of the bat file and the cmd window to see what is going on.

 

[Sebastian42]

Here it is

 

[newtekie1]

The bat file can't be named Robocopy.

 

[Sebastian42]

Changing the batchfile name made all the difference.
It's reporting many files as corrupt/unreadable - not clear to me whether they are on the source or the target.
The process finished in mere minutes

 

[newtekie1]

Usually corrupt/unreadable is an issue with the source.

 

[Solaris17]

Are you trying to R/W system files with that batch when you are getting those errors? Are you running it as admin? That will likely cut them down (not get rid of) but robocopy will work in uset context. So if you are running as you and not elevating those errors make sense.

Its not going to let you make modifications to system files, you don't have the proper privileges. As mentioned, even as Admin though, some may be protected by SYSTEM and you still wont be able to touch them.

 

[Sebastian42]

Newtekie1 - it very intuitive that the source would be the problem; but I redid the whole exercise with a different EMPTY target USB, and there was NO mention of corruption. The time taken was even longer than the one I complained about in my first post. The first target could no longer be accessed, and I have disposed of that USB. I can't see that anything can be gained by using Robocopy over the performance of the cloner, which had done an adequate job in a short time - until the incident that triggered my post.

Solaris 17 - NO system files; just 'reserve' installation files for programs that had already been installed on a HDD. I was not running the batch 'as admin'. Your cautions are not applicable as the material was just data - NO system files.

I'm happy to now 'put paid' to this issue - and look forward to improved performance when the larger USBs arrive.

 

[newtekie1]

Newtekie1 - it very intuitive that the source would be the problem; but I redid the whole exercise with a different EMPTY target USB, and there was NO mention of corruption. The time taken was even longer than the one I complained about in my first post. The first target could no longer be accessed, and I have disposed of that USB.

That's why I said usually. However, if the destination drive drive is bad, it can also cause read/corruption errors because of how Robocopy check to make sure the files have been copied properly.

I can't see that anything can be gained by using Robocopy over the performance of the cloner, which had done an adequate job in a short time - until the incident that triggered my post.

It probably won't be any faster regardless of what software you use. The file transfer is usually go to be limited by the write speed of the USB flash drive. But the point in using Robocopy is you won't get stupid incorrect file system errors.