large difference between bytes and MB used in Finder info

[camner]

I did a Get Info on a folder, and I saw this:

I don't understand how 875,094,400 bytes gets "converted" to 965.7 MB. I have seen small discrepancies before, but never 90MB worth. Then, at the top of the Get Info, it says 875.1MB, which is what I'd expect.

What's going on here?

 

[JustAnExpat]

Could it be because of this?

Gigabyte - Wikipedia

en.wikipedia.org

The Finder is reporting the proper size of the file in bytes, but because of rounding it's reporting a much larger size in MB?

Another reason is because it's comparing the actual file size (in bytes) to the size consumed on the disk (in MB) because of the file block size due to APFS?

https://www.ntfs.com/apfs-structure.htm

Each block is 32 bytes in size, so if you have a lot of small items, it'll take up much more space.

 

[velocityg4]

Actual bytes as the computer sees them is calculated in Base-2. macOS reports in Base-10. Probably to try and stop the angry calls from people whose storage space doesn't match the advertising literature and don't know the difference.

Data storage values

 

[camner]

Thanks for your quick reply. There are only 9 items in the folder, so I wouldn't think the 2nd possible explanation would play much of a role here. And I don't see how rounding could cause

 

[camner]

Thanks both for your replies, but neither explanation is consistent with what I am seeing. In the case of one folder, there is no discrepancy, whereas with a different folder, there is a significant 90 MB discrepancy. The factors you outline should affect how both folders' sizes are displayed, correct?

 

[svenmany]

Thanks both for your replies, but neither explanation is consistent with what I am seeing. In the case of one folder, there is no discrepancy, whereas with a different folder, there is a significant 90 MB discrepancy. The factors you outline should affect how both folders' sizes are displayed, correct?

The discrepancy of the interpretation of MB doesn't explain it. Whether it's (965.7 * 1024 * 1024) or (965.7 * 1,000,000), the number is way more than the number of bytes shown.

It has to be something about wasted space on disk. I wonder, if you move the files off of the drive, onto some other drive, and then move them back, does it change?

 

[jkreileder]

Block size is usually 4k (see "diskutil info / | grep Block" in Terminal), so up to 4093 bytes are wasted per file.

 

[svenmany]

Block size is usually 4k (see "diskutil info / | grep Block" in Terminal), so up to 4093 bytes are wasted per file.

Is there only one block per file that might not be fully consumed?

 

[jkreileder]

Is there only one block per file that might not be fully consumed?

Just the last. Most filesystem try to reduced wasted space (fragments, subblock allocation, ...) but I have no idea if APFS does.

Also, the first number actually can be bigger than the later:

That happens with sparse files (i.e. files with lots of null bytes).

 

[camner]

My interest in these figures is that I am trying to determine the amount of savings that various compression methods give me. Which figure should I be using to compare before compression to after? The first figures, given in bytes, or the second, given in MB?

 

[Nermal]

I think it might be prudent to do Get Info on each of the 10 files and see whether it's any particular one that's 'grabbing' all the extra space, or whether it's spread out evenly. I can't think of a logical reason for such a large "on disk" size for just 10 files.

 

[camner]

The files are TIFF image files. One of them is a 16-bit tiff from an original 48MP DNG. That's the huge one.