René Bertin
René Bertin
Can you check and close the issue if this now gets your approval? :)
So basically it's a factor 1000 (1024) off? I don't understand this, and in fact I remember that I couldn't even reproduce your original observation. Looking at the function that...
It is until we understand what's going on. If it miscompiles this code, who knows what else it miscompiles?
> size: 1382668, size_rounded: 276824064 > > This doesn't look right. The problem seems to be with the `size_rounded` value that's passed in. No, that doesn't look right, esp. since...
A thought: what filesystem are you seeing this with? Is that by any chance on APFS?
Thanks for confirming. Still a considerable difference (over 200000 bytes) but this does look more reasonable, no? Apparently we have to find the HFS-specific contribution to the rounded file size...
You're right that the code is very noisy and repetitive. I don't feel very much like giving it the required overhaul, though ... Could I ask you to try to...
Oh, and if it really interests you, try a disk benchmarking utility that allows you to use 4Mb (and larger) block sizes. I don't know what kind of drive you...
Meanwhile, I pushed a couple of changes (including one which should let cmake find sparsehash *if* you build for installing into the same prefix (/opt/local, right?). I think I found...
>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? Yes. I think...