Re: Zero padded file modes...

>
> I haven't looked carefully at the pack v4 patches yet, but I suspect
> that yes, it's still a problem. The premise of pack v4 is that we can do
> better by not storing the raw git object bytes, but rather storing
> specialized representations of the various components. For example, by
> using an integer to store the mode rather than the ascii representation.
> But that representation does not represent the "oops, I have a 0-padded
> mode" quirk. And we have to be able to recover the original object, byte
> for byte, from the v4 representation (to verify sha1, or to generate a
> loose object or v2 pack).
>
> There are basically two solutions:
>
>    1. Add a single-bit flag for "I am 0-padded in the real data". We
>       could probably even squeeze it into the same integer.
>
>    2. Have a "classic" section of the pack that stores the raw object
>       bytes. For objects which do not match our expectations, store them
>       raw instead of in v4 format. They will not get the benefit of v4
>       optimizations, but if they are the minority of objects, that will
>       only end up with a slight slow-down.
>
> As I said, I have not looked carefully at the v4 patches, so maybe they
> handle this case already. But of the two solutions, I prefer (2). Doing
> (1) can solve _this_ problem, but it complicates the format, and does
> nothing for any future compatibility issues. Whereas (2) is easy to
> implement, since it is basically just pack v2 (and implementations would
> need a pack v2 reader anyway).