File systems of USB sticks

[Sebastian42]

For the sake of getting a backup, I wanted to clone (the contents of) one USB stick, to another of the same nominal size. The cloning program said it was not possible to do that amount in FAT, and I allowed it to proceed in NTFS. It took hours to do that, when previous cloning (without file system change) had taken 15 min. After cloning finished I checked the properties of the clone, and it showed FAT32, NOT NTFS. The cloner's claim that it could only happen in NTFS proved to be false. Can anyone explain to me why the cloner objected, but then proceeded anyway ?

 

[Rei]

1) What cloning program did you use?
2) What are the sizes of both your USB flash drive?
3) Are you using the latest version of your cloning program?

 

[Sebastian42]

1 Casper v8
2. 16Gb
3. No.

 

[ebivan]

Why clone? This ist normaly only needed for devices with bootable flags or filesystems that you cant normally use under the host os.

If there are just a bunch of files on that stick, why not just do a ragular copy of those?

Generally i would recommend using exFAT for usb sticks, its usable with all major OSes, has no problem with modern FS sizes and file sizes.

 

[Sebastian42]

Why clone ? - because it is really just updating - very little change - but I want a backup of the latest. Copying would add all the new material, but not remove changes to existing entries. Unless I format the USB first, then EVERYTHING has to be recopied making it a much bigger process, taking longer. Actually, I suspect that the complaint about file format is a red-herring, triggered by the fact that there is less than 1Gb of space left on the USB. I've been meaning to put those contents on bigger USBs, but I have been let down by non-delivery of ordered items.

 

[ebivan]

Cloning literally means to copy everything.
What you mean would be called syncing (for example with rsync) this technique allows to only write changed data to a disk.

 

[Rei]

Whoops, forgot to reply to this thread. My bad...
I agree with @ebivan here in just using the regular copy/paste method if the content of the USB flash drives are just data files & not system files. Just overwrite existing files with the newer ones. No need to make it harder on yourself. Depending on your USB speed, this only takes somewhere between a minute to 20 minutes. Cloning is best suited when dealing with system files & registries.

 

[Sebastian42]

Ebivan - now that I know the correcte terminology - syncing - can you tell me what program/process does syncing ?

Rei - yes the contents are 'data' files - NOT system ones; I repeat that copying would update new material, but not remove now-obsolete entries. I agree about the time required - that is what it (cloning) used to take before the demand for File System Change.

 

[newtekie1]

Learn how to use Robocopy and you won't look back.

 

[Sebastian42]

Newtekie - can you guarrantee that Robocopy will remove from the target, material that is not in the source ?

 

[ebivan]

I only use syncing on Linux. There 'rsync' is the program that does the job. Just google ist, it is very well and extensively documented.
I dont know if there is an equivalent for that in windows but I am pretty sure that Powershell must have something similar as it is a pretty basic functionality. Otherwise I just did a quick search and Robocopy seems to be what you are looking for.

 

[Sebastian42]

I'll give Robocopy a go. Thank you. I hope the larger USBs arrive soon - I expect the problem will not occur then.

 

[Ricktheslickster]

For the sake of getting a backup, I wanted to clone (the contents of) one USB stick, to another of the same nominal size. The cloning program said it was not possible to do that amount in FAT, and I allowed it to proceed in NTFS. It took hours to do that, when previous cloning (without file system change) had taken 15 min. After cloning finished I checked the properties of the clone, and it showed FAT32, NOT NTFS. The cloner's claim that it could only happen in NTFS proved to be false. Can anyone explain to me why the cloner objected, but then proceeded anyway ?

I don't think it would have mattered what format you formatted the target drive to, once you begin your cloning software, the target drive will take on whatever the source drive is formatted to. I mean, after all, that's what you are trying to do isn't it, to "CLONE" the source drive? So logically wouldn't the target machine take on the same format of the source drive as part of the cloning process? If it didn't I wouldn't consider your cloning soft5ware to be a good cloning app.

 

[Sebastian42]

Which explains why the format of the target remained the same despite the threat that the old format was unsuitable.

 

[Sebastian42]

RoboCopy may well do what it is claimed to do but its interface is SO daunting that It would be simpler to reformat the target and just copy to it.

 

[newtekie1]

Newtekie - can you guarrantee that Robocopy will remove from the target, material that is not in the source ?

If you tell it to do that, yes it will do that.

RoboCopy may well do what it is claimed to do but its interface is SO daunting that It would be simpler to reformat the target and just copy to it.

You just have to write the command line once, save it to a bat file, and then run the bat file any time you want to do the sync. This works wonderfully as long as the source and destination keep the same drive letters.

 

[Sebastian42]

Newtelie1 - if you write me a sample command line that I can adapt, I'll put it into a batch file, and run it on the same two USBs and report the results.

 

[newtekie1]

E:\ is the source.
F:\ is the destination.
Change these to match the drive letters of your flash drives.

DO NOT mix up the source and destination. If you are trying to copy a drive to a blank drive and mix up the drive letters, it will wipe the drive with all the data.

This won't copy the System Volume Information folder, which can't normally be copied anyway, and usually doesn't exist on flash drives anyway. But I include the part to skip it just in case, because it makes the script run faster when there is a System Volume Information folder. Because it won't waste time trying to retry copying.

This also sets it so robocopy will only try to retry copying a file 5 times if it can't copy the file on the first try. And it will wait 5 seconds before trying to retry copying the file. You can adjust these if you want.

The /Z flag makes robocopy use restartable mode. This means if robocopy is copying a file and the script stops for some reason part way through the file copying, the next time you run the script it will finish copying the file instead of copying the whole file as long as the file hasn't changed. You may have to run the bat file as administrator because of this flag. If you don't want to do that, just remove the /Z.

The pause at the end on the second line just makes it so the cmd window stays open when the robocopy script is done, so you can see that it finished. It will prompt you to press any key and the window will close when you do. You can remove this if you prefer the window to just close when Robocopy is done.

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

 

[Sebastian42]

My source comes up as D - I notice you have 'XD' in the code - can I safely change the source in the code to D and the target to E ?

 

[newtekie1]

Yes. leave the XD alone. XD just means eXclude Directory. But you can change the E:\ to D:\

 

[Sebastian42]

Forgive me if my response seems convoluted.
To get an accurate comparison of results between cloning and using RoboCopy, I decided to use the original souurce and original target USB sticks.
At the time that I made my previous post, I had tried to do this 'experiment' in a separate PC (with a 64bit version of Win10ProV20H2), kept specifically for trialing purposes. In that PC, the source USB showed as D. Then I asked you whether leaving it as D would work, since you have an 'XD' term in the code.
Having found Robocopy.exe (2019) in \Windows\ in the PC I am writing you from (32bit Win10ProV20H2), I expected to find that in the 64bit PC as well - but NO, all it had, was the EasyRobocopy I recently installed, because 'you' had recommended RoboCopy to me; so I figured that I could not expect the batch file to work there.
So instead, I tried the batch file in a clone of this 32bit system. The source USB already has the drive letter U allocated, so I kept that ,and designated the target as V and altered the code to say "robocopy U:\ V:\ /U /Z /XD "System Volume Information" /R:5 /W:5 /PURGE"
On running it, the first attempt mentioned an error #3 : U.
I found that I had made a mistake in the REM, leaving 'F' instead of replacing it with 'V' - so I corrected that. As far as I know, whatever follows REM has NO influence on the running of a batch file. I ran the batch again, and there was NO visible reaction.

 

[newtekie1]

Don't change the /E to a /U. The only part of the command line that are drive letters are E:\ and D:\, those are the only things you change.

If your flash drives are U and V then the command should look like:

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

And robocopy should be located in \Windows\System32 on your 64-bit system.

 

[Sebastian42]

My error - in 32bit, Robocopy is ALSO in \C:\Windows\System32\ !

I am running it in the 64bit system for D & E, but I believe the contents are still identical (or almost so).
There is much activity , but It is incessantly showing/repeating the same line in a 'DOS' window - I'd expect it to change depending on which file it was copying.

 

[newtekie1]

It should show each file it is copying and the percentage of that file copied.

 

[Sebastian42]

Definitely NOT doing that. I have edited my last post a number of times, probably since you replied to it.
Since it is not behaving the way you expect. I will terminate the process and hope no damage has been done to the source USB