On 07/05/2022 03:15, Jason Hatton wrote:
Philip Oakley <philipoakley@iee.email> writes:
This may treat non-zero multiple of 4GiB as "not racy", but has
anybody double checked the concern Réne brought up earlier that a
4GiB file that was added and then got rewritten to 2GiB within the
same second would suddenly start getting treated as not racy?
This is the pre-existing problem, that ~1in 2^31 size changes might not
get noticed for size change. The 0 byte / 4GiB change is an identical
issue, as is changing from 3 bytes to 4GiB+3 bytes, etc., so that's no
worse than before (well maybe twice as 'unlikely').
OK, it added one more case to 2^32-1 existing cases, I guess.
The patch (the firnal version of it anyway) needs to be accompanied
by a handful of test additions to tickle corner cases like that.
They'd be protected by the EXPENSIVE prerequisite I would assume.
Oh, absolutely. Thanks for spelling that out.
I have been testing out the patch a bit and have good and (mostly) bad news.
What works using a munge value of 1.
$ git add
$ git status
Racy seems to work.
$ touch .git/index 4GiB # 4GiB is now racy
$ git status # Git will rehash the racy file
$ git status # Git cached the file. Second status is fast.
What doesn't work.
$ git checkout 4GiB
$ fatal: packed object is corrupt!
Using a munge value of 1<<31 causes even more problems. The file hash in the
index for 4GiB files (git ls-files -s --debug) are set to the zero file hash.
I looked up and down the code base and couldn't figure out how the munged
value was leaking out of read-cache.c and breaking things. Most of the code
I found tends to use stat and then convert that to a size_t, not using the
munged unsigned int at all.
Maybe someone else will have better luck. This seems over my head :(
Thanks
--
Jason
Is there a problem that 1<<31, when on a 32bit long is MAX_NEG, rather
than being MAX_POS? And the size would need to be positive to be an
acceptable file size?
(The code is a bit of a mish-mash on the Windows LLP64 side, where long
is only 32 bits).
Philip
Apologies for the terseness.
