Takes significantly longer to write a .vhd to USB compared to manually partitioning and copying files.

[higbyk]



Checklist

• [x] I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• [x] I performed a search in the issue tracker for similar issues using keywords relevant to my problem, such as the error message I got from the log.
• [ ] I clicked the 'Log' button or pressed Ctrl-L in Rufus, and copy/pasted the log into the line that says <FULL LOG> below.
• [ ] The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• [x] I ran a bad blocks check, by clicking Show advanced format options then Check device for bad blocks, and confirmed that my USB is not defective.
• [x] I also tried one or more of the following:
  • [x] Using a different USB drive.
  • [x] Plugging the USB into a different port.
  • [x] Running Rufus on a different computer.
• [ ] If using an image, I clicked on the (✓) button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.

Issue description

I combined several USB diagnostic tools we use at work into one multiboot USB and copied the working disk to a .vhd using Rufus. I'm now in the process of updating all our USBs to the new utility, but I've noticed that it takes far longer to image this .vhd using Rufus than to manually create the partitions and copy the contents into each from the mounted VHD.

My .vhd was created in Rufus from a working disk with the following partitions: 2GB FAT (WinPE); 500MB FAT (SeaTools); 200MB FAT (OEM BIOS TOOL); ~26GB unallocated.

Since I haven't been able to find the answer elsewhere: How does Rufus write a .vhd image to disk?

I always assumed that it: 1) creates the partitions present in the .vhd and 2) copies the files over to their respective partitions. Therefore it shouldn't take longer than it takes to format partitions and copy ~2GB of content.

However it appears Rufus is just copying the .vhd to disk bit by bit, including the 26GB of unallocated space at the end of the drive (for adding additional tools).

Is this actually what it's doing? Is there an efficient way to accomplish this with Rufus, or should I script it?

Log

I can include a log if requested, but it will take ~40min to image to produce the log. I started imaging manually after the first three and don't have a log available.

[pbatard]

I always assumed that it: 1) creates the partitions present in the .vhd and 2) copies the files over to their respective partitions.

I'm afraid you are assuming wrong.

However it appears Rufus is just copying the .vhd to disk bit by bit, including the 26GB of unallocated space at the end of the drive.

Yes, that is exactly what it is doing, because the use of VHD is meant to be a 1:1 copy of the original, including all of the unused data (which may or may not be set to 0).

As far as Rufus is concerned, VHD and DD mode are the exact same thing, so if you want file copy, you will need to use a different mode.

If I were you, I would be looking at using dism.exe and the FFU file format (which we may add support in Rufus at a later stage... if Microsoft stop screwing up by providing a crippled API for it that does not allow cancelling or report any progress whatsoever).

As I believe I have answered your question, I will close this issue.

[higbyk]

Thank you very much, that answers my question perfectly.

In that case, I'll modify the VHD to remove the unallocated space. I've used DISM to customize WinPE for our purposes, but I don't know anything about the FFU file format. Looking into it now.

Thanks for all you do, it makes a huge difference on the daily for me.

[pbatard]

I'll modify the VHD to remove the unallocated space.

Yeah, the uncompressed VHD format, which is what Rufus saves to, is fairly straightforward, as it's just a bit to bit copy of the source disk, with a 512 bytes footer added. So you should indeed be able to hack away the parts that you don't want.

But I'm hoping that you'll find that Microsoft's relatively new FFU file format might be even more suitable for what you plan to do (though you may have to use a recent version of Windows 10 to be able to work with .ffu files). As much as I'd like to see Rufus everywhere, and I tried to add "convenience" features such as saving to VHD, I also know that it's not always the right tool for the job, so make sure to explore all your options.

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.