I have a 2TB hard drive "D" containing 732GB of data on a 2TB NTFS partition that I want to copy (absolutely everything on the drive) to another drive "F" with 981GB of space (its freshly formatted (NTFS)).

I made sure no processes were writing to disk D or F. Only a backup process was running (backblaze) and I assume it only does read operations so it should be no problem.

I started the copying through an administrator elevated command prompt:

C:\Users\Me\Desktop\: xcopy /x /o /h /e /k D: F:

Then after about 20 hours, the command failed saying "insufficient space". I checked in explorer and disk F is indeed 100% full. Disk D didnt grow or anything, still only 732GB in use.

I'm clueless here. Why is the data suddenly larger? Should I try using a live cd such as clonezilla?

(Side question: can I speed this process up somehow?)


Based on suggestions I've tried the following:

robocopy D:\ F:\ /COPYALL /E /DCOPY:T /R:10 /LOG:copylog.log /XD .bzvol

I excluded .bzvol (which is only 82 KB) because it confuses backblaze if I don't!

This resulting in 'endlessly' repeating this message once F was full: ERROR 112 (0x00000070): There is not enough space on the disk. Waiting 30 seconds...

Here's some visual evidence:

enter image description here

I checked and drive D is not set to "Compress this drive to save disk space".

Drive D is encrypted by TrueCrypt 7.1a. It's mounted currently while I'm copying. But that shouldn't be a factor here, I think.


Based on new feedback, I've gathered some statistics on the two partitions. Charl's was right on the money. Cluster size was significantly larger on the target disk. I'm wondering which of the two is the "correct" (better) setting of the two, but for the copying to succeed I won't have much of a choice anyhow. Thanks for the help everyone.

enter image description here

enter image description here

  • 1
    Maybe xcopy require swap space of sorts. Try using Robocopy - it's better suited for coping large amounts of files.
    – EliadTech
    Jun 28 '14 at 22:34
  • Could it be that some of the files and folders on the source drive are compressed? Copying them to a new volume should cause them to inherit the destination volumes compression state, which I'm assuming is uncompressed.
    – joeqwerty
    Jun 29 '14 at 4:27
  • I updated the question to address all your comments. Still unsolved.
    – Korijn
    Jun 29 '14 at 10:02
  • In those fsinfo screenshot I'm seeing equal cluster size, or am I missing something? Jun 29 '14 at 20:38
  • Bytes per physical sector! Wow I just realized this is not gonna work out for me at all! Haha. Jumped to a conclusion there. All this thesis work has gotten the best of me.
    – Korijn
    Jun 29 '14 at 20:42

What is the cluster size (allocation unit size) on your source volume D (actually on the filesystem inside your TrueCrypt container) and on your target volume F?

One hypothesis for the drive filling up, is that volume F has a larger cluster size, and volume D has many small files. This would mean that the same data could take up significantly more space on destination volume F than on source volume D.

  • I'll check it out immediately and update the answer in a few (hi!).
    – Korijn
    Jun 29 '14 at 20:17
  • Right on the money!
    – Korijn
    Jun 29 '14 at 20:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.