I am trying to copy the contents of one hard drive to another hard drive.

But once the copy is completed, the copy takes up less space than the original files.

Hence not all files are being copied.

I suspect this might be because after a certain number of folders, the files are not being copied.

Is this correct? And if so, how can I prevent this from happening?

OS: Windows 8.1 Pro


I'm trying on Linux now and am going to see if the same happens.

  • 1
    Please edit your question to provide more details. Such as what OS you are on, what the expected size of the copy should have been as well as what it ended up being? Oct 12, 2015 at 23:47
  • Also, getting the number of files should not be a problem
    – clhy
    Oct 13, 2015 at 0:00
  • 2
    It is possible there are hidden or system files you do not have access to. Do you have attributes set to have access to them all?
    – CharlieRB
    Oct 13, 2015 at 0:28
  • another note: the size on disk is affected by fragmentation. The ending file size should be smaller if you're going by that record of the two. (Assuming the older location was fragmented.)
    – NBN-Alex
    Oct 13, 2015 at 0:32
  • 1
    Don't forget cluster size can also effect size on disk.
    – Tyson
    Oct 13, 2015 at 1:27

1 Answer 1


Short answer:
Not necessarily. It can be only the different cluster size between the devices.

Some words more:
When you copy a file from a device to another (from an HDD to another) you have to consider even the different cluster sizes. Without entering too deep inside the zoo of file system type it's enough to say here that a partition is organized as an arithmetic exercise book, the bytes are grouped in sector in a similar way in which in the exercise book you can say that the squares are grouped in pages. The index of the free and used space (FAT) is made considering only those groups. The sectors can be or free or full, tertium non datur.

So a file has a size for the effective bytes used (if it is a text file and contains only the word "Hi" it will be 2Bytes), and a size for space used on the device (if a sector is of 4kB it will be a multiple of 4kB, if on another device the sector is of 512 bytes it will be a multiple of 512B).

On the other side it's possible that copying a large number of files you can have errors in writing or reading operations, you can have no right to access to the some file, or some file can be deleted in the meanwhile if the operation is long and the file is a temporary one.

This is usually notified by the program you are using with some error message and with an error exit code. Under Linux for example, you can catch the exit code by writing in the shell echo $?. If it returns a value different from 0 it means error. If you haven't catch those messages in advance, you have to check it a posteriori.

After that you copied a large number of files you can check, quickly, if the number of the files and the total effective bytes count matches. A more effective check can be done computing and comparing the md5sum for each file on both the copies. If this match all the contents are Ok. Least you may want to check the permission and date.

Often is cosy to rely on specific tools as rsync for Linux, robocopy for Windows, or one of the many many other tools available.

  • Interesting. A lot of that went over my head in the first read. I honestly never expected file systems and the "allocation unit size" (I assume that's what you were referring to?) to affect how much space a file would take up on a storage device! Thanks a loads!
    – user138072
    Oct 13, 2015 at 14:14
  • You're welcome. I cannot know from here if it is this the cause, but I rely on this steps to find if it is. BTW I didn't have more time to write it simpler.
    – Hastur
    Oct 13, 2015 at 15:17

Not the answer you're looking for? Browse other questions tagged .