Why do sizes and file counts differ after copying data?

sbhenkel wrote:

That's kind of what I was leaning towards. It's hard to imagine something as basic as a copy (or drag) command having a problem. I guess the question is, could your answer account for that much difference? It seems a lot but how can you know.

I don't want to go too far into the weeds with this but is there any other way if they're the same,

outside of having a program read each and every file and compare? I'm thinking that if the consensus of answers here are that it's safe to assume they're the same regardless of the numbers, then I'll just drop it.

I just thought of a way to test your theory. I'm going to take the contents of the destination folder (possibly more contiguous) and copy them to yet another empty folder. I'll let you know what the size difference is.

You are all ready in the weeds giving it so much attention...

From the the Terminal.app you can Compare two folders:

diff -r --brief --exclude=.git /path/to/folder1 /path/to/folder2  

All differences are listed in the output...

if you are returned to the prompt with no difference list...they are exactly the same.

ref:

Terminal User Guide for Mac - Apple Support

1) It is possible the original files were created with

ditto --hfsCompression

see

man ditto

And copying the file expanded the file to its full size.

Using the 'wc -c /path/to/file' command against a sample file on the external disk and the copy should show the same character count, but if the allocations are different (ls -l -s /path/to/file), this could indicate the smaller file has been subjected hfsCompression.

There is utility you can install via Homebrew (https://brew.sh) that can both hfsCompress a file in place, as well as tell you if the file is hfsCompressed.

brew install afsctool
afsctool -v /path/to/the/file

afsctool -v tmp.tmp
/Users/me/Downloads/tmp.tmp:
File is HFS+/APFS compressed.
Compression type: ZLIB in resource fork (4)
File content type: dyn.ah62d4rv4ge81k5pu
File size (uncompressed; reported size by Mac OS 10.6+ Finder): 1466060 bytes / 1.5 MB (megabytes, base-10)
File size (compressed): 204800 bytes / 200 KiB
Compression savings: 86.0%
Number of extended attributes: 0
Total size of extended attribute data: 0 bytes
Uncompressed file size reported in compressed header: 1466060 bytes

2) As Old Toad says, there may be more metadata being used to keep track of the file copy vs how it is stored on the external drive.

3) It is possible that the external drive has a smaller minimum allocation unit size. For example if the external file system used 512 byte minimum allocation, but the file system with the copy uses a 4K minimum allocation, then the statistical average will have each external disk file grow by 2K (some will not grow at all, and some will only need an extra 512 bytes, but some will need and extra 3,584 bytes; but the average will be 2K). If there are a lot of small files, this can add up.

sbhenkel wrote:

I had two folders on the same external hard drive open in Finder. One was empty. The other had data in it. In the folder that had data I did command-A to select everything and then did command-C. I then went to the empty folder and did command-V. When it was all done, the get-info on the source folder said 17,111,798,393 bytes while the destination folder said 14,946,153,439 bytes. Both said 8 documents and 9 folders.

I drilled down into one of the folders and did get-info on them. The source folder said 4,659,612,112 bytes (10.72 GB on disk) for32,182 items. Get-info on the same folder in the destination said 2,936,187,379 bytes (7.88 GB on disk) for 25,508 items.

I've only had a Mac for 9 months. Does this sound normal? Do I need to be concerned? The numbers would indicate I've lost data on the copy but common sense tells me that a bedrock common like copy and paste can't be having that kind of problem.

You can always experiment more (?)

different folders...

different method... ie drag and drop and compare your results...

report back your findings.

You can be as concerned as you want to be. How often is it an issue for you? One off issue or on going...?

You can always Call Customer Support (800) MY–APPLE (800–692–7753)

or on line Apple Support

Outside the USA—Contact Apple for support and service by phone

See a list of Apple phone numbers around the world.

Contact Apple for support and service - Apple Support

The original folder may have its files scattered over the drive in bits and pieces and the copied version is contiguous. The could account for the difference.

sbhenkel wrote:

It appears you've learned a lot and have been around the block a few times. Your "diff" command was a good suggestion. It showed me that there are some hidden dot files involved. I'll have to read up on those.

[Edited by Moderator]

Good computing sbhenkel !