Unable to copy 3.99 GB file to FAT32 USB Drive

I have a bootable USB flash drive (formatted FAT32) which I use to boot my system image software when I want to do a system restore.

On that same drive, I store the backup images for my software and since the drive is FAT32, the maximum file size is 4GB; therefore, I make sure that I configure my system image software to create backup files of 4GB max. When I did the last system image, the total backup size was 18.2GB, split into four 4GB files plus one 2GB file; those files are stored on an NTFS-formatted USB drive.

When I then attempt to copy all those 5 files onto my bootable USB flash drive, one of the 4GB files fail with the error "An error occurred copying '': There is not enough space on the disk. (112)"; however, Windows File Explorer is able to copy all the files to the USB flash drives no problem and that's what I had to end up using. Here are the Properties information (i.e., right-click and select Properties) about the four 3.99GB files:

  1. Size: 3.99 GB (4,294,916,801 bytes); Size on disk: 3.99 GB (4,294,918,144 bytes)
  2. Size: 3.99 GB (4,294,925,841 bytes); Size on disk: 3.99 GB (4,294,926,336 bytes)
  3. Size: 3.99 GB (4,294,955,665 bytes); Size on disk: 3.99 GB (4,294,959,104 bytes)
    4) Size: 3.99 GB (4,294,965,217 bytes); Size on disk: 4.00 GB (4,294,967,296 bytes)

It is file #4 that DOpus fails to copy, but Windows File Explorer has no problems copying it.

I am using DOpus 10.5.4.0 (5080) x64 on Windows 8 Pro.

Thanks for reporting this, and all the details.

The issue is caused by non-buffered I/O needing to round-up file sizes, and then truncate the extra once the file has been written. In the case of your 4th file, the rounding up is causing the file to be too large for FAT32's 4GB limit.

As a temporary workaround, disabling non-buffered I/O will prevent the problem. You can disable it by setting Preferences / Miscellaneous / Advanced: copy_nonbufferio_threshold to 0 (zero).

We'll have a fix for this in the next update, so that the workaround is no longer needed.

Thank you!