This is a critical bug fix for a data corruption bug. If you

maintain another tree then please apply!

On non-X86 machines out byte-order macros fails for one particular
value. If you asked for IVAL() of 0xFFFFFFFF and assigned it to a 64
bit quantity then you got a 63 bit number 0x7FFFFFFFFFFFFFFF rather
than the expected 0xFFFFFFFF. This is due to some rather bizarre and
obscure sign extension rules to do with unsigned chars and arithmetic
operators (basically if you | together two unsigned chars you get a
signed result!)

This affected a byte range lock using the large lockingX format and a
lock of offset 0 and length 0xFFFFFFFF. Microsoft Excel does one of
these locks when opening a .csv file. If the platform you run on does
not then handle locks of length 0x7FFFFFFFFFFFFFFF then the posix lock
fails and the client is given a lockingX failure. This causes the .csv
file to be trunated!!
(This used to be commit 886661c3777dbfd4fa431746c8a5f48674a12b8e)

0 files changed, 0 insertions, 0 deletions