RE: [BUG] 2.44.0 t7704.9 Fails on NonStop ia64

[<rsbecker@nexbridge.com>]

On Tuesday, February 27, 2024 9:22 AM, Patrick Steinhardt wrote:
>On Tue, Feb 27, 2024 at 09:10:55AM -0500, rsbecker@nexbridge.com wrote:
>> On Tuesday, February 27, 2024 3:46 AM, Patrick Steinhardt wrote:
>> >On Mon, Feb 26, 2024 at 03:32:14PM +0000, Phillip Wood wrote:
>> >> Hi Randal
>> >>
>> >> [cc'ing Patrick for the reftable writer]
>> >>
>> >> > The question is which call is bad? The cruft stuff is relatively
>> >> > new and I don't know the code.
>> >> >
>> >> > > > reftable/writer.c:              int n = w->write(w->write_arg,
>> zeroed,
>> >> > > > w->pending_padding);
>> >> > > > reftable/writer.c:      n = w->write(w->write_arg, data, len);
>> >>
>> >> Neither of these appear to check for short writes and
>> >> reftable_fd_write() is a thin wrapper around write(). Maybe
>> >> reftable_fd_write() should be using write_in_full()?
>> >
>> >It already does starting with 85a8c899ce (reftable: handle
>> >interrupted
>> writes, 2023-12-11):
>> >
>> >```
>> >static ssize_t reftable_fd_write(void *arg, const void *data, size_t sz)
{
>> >	int *fdp = (int *)arg;
>> >	return write_in_full(*fdp, data, sz); }
>>
>> Unfortunately, this fix is included in what I am testing but does not
>> impact the issue I am seeing one way or another, but thank you.
>
>I didn't expect it to :) The mentioned commit only fixes things with the
reftable backend, which is not tested by default. I assume that
>you didn't run tests with GIT_TEST_DEFAULT_REF_FORMAT=reftable, and thus
>t7704 wouldn't use the reftable code in the first place.

That is correct, I did not. Thanks.