Incorrect display of folder sizes in human readable form about afsctool HOT 21 OPEN

from afsctool.

It's cosmetic, so obviously not a big deal.

The biggest reason to fix it is that when someone notices it for the first time, it is not immediately obvious that it's cosmetic, and people may get worried about possible data loss (afsctool can be scary to use). I was certainly a bit worried until I realized that the byte count is correct.

As for 1024 vs 1000, it's really not a big deal. Most other command line tools, like ls -lh, use 1024, so why not go with that? (The Finder uses 1000, which is annoying.)

from afsctool.

Can you check and close the issue if this now gets your approval? :)

from afsctool.

Sorry for the late response. I am not sure what is happening, but it still doesn't report sizes correctly. I double-checked that I am using the version I just built (and the source I just downloaded).

For example, for the folder where I built it, it says

Folder size (uncompressed; reported size by Mac OS 10.6+ Finder): 1387738 bytes / 276.8 MB (megabytes, base-10)
Folder size (compressed - decmpfs xattr; reported size by Mac OS 10.0-10.5 Finder): 1387738 bytes / 276.8 MB (megabytes, base-10)
Folder size (compressed): 1387738 bytes / 264 MiB

from afsctool.

from afsctool.

I'm not really familiar with cmake, so all I did was

cmake .
make

It would complain about not finding sparsehash/dense_hash_map, so I added /opt/local/include to target_include_directories, which seemed to work.

I built it on OS X 10.13.1 with the latest dev tools ("Apple LLVM version 9.0.0 (clang-900.0.38)")

from afsctool.

But since it's just a misreporting, it's really not a big deal.

from afsctool.

from afsctool.

Weird indeed. I can't see the problem in the function. Will look more later. Here the output is fine: http://coliru.stacked-crooked.com/a/e04c6526167906df

from afsctool.

I won't have more time for this today, but I put a printf at the beginning of getSizeStr to see what arguments it's getting, and I see this:

size: 1382668, size_rounded: 276824064

This doesn't look right. The problem seems to be with the size_rounded value that's passed in.

from afsctool.

from afsctool.

from afsctool.

Yes, APFS.

I just tried on HFS+ (external drive) and it looks fine there:

size: 15329972233, size_rounded: 15330181120
Folder size (uncompressed; reported size by Mac OS 10.6+ Finder): 15329972233 bytes / 15.33 GB (gigabytes, base-10)

from afsctool.

from afsctool.

st_blksize (for one file) is 4096 on the HFS+ volume I tried. On the APFS one it is 4194304 = 2^22. That explains the large reported sizes, but I do not know much about file systems, so I don't know what this value means in practice (I prefer not to guess in public :) )

from afsctool.

I find the code a bit too noisy to follow with confidence, but there are several repeated bits that seem to round up filesize to a multiple of fileinfo->st_blksize, like here:

filesize_rounded = filesize = fileinfo->st_size;
filesize_rounded += (filesize_rounded % fileinfo->st_blksize) ? fileinfo->st_blksize - (filesize_rounded % fileinfo->st_blksize) : 0;

from afsctool.

from afsctool.

I don't know the background context.

Do you mean that the whole purpose of this complicated calculation and rounding to "block sizes" (whatever those may be) is just to reproduce the Finder's results?

So you are asking to look at what the Finder reports on 10.13 / APFS and see which calculation it matches with?

from afsctool.

from afsctool.

from afsctool.

from afsctool.