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:

quoted

On Tuesday, February 27, 2024 3:46 AM, Patrick Steinhardt wrote:

quoted

On Mon, Feb 26, 2024 at 03:32:14PM +0000, Phillip Wood wrote:

quoted

Hi Randal

[cc'ing Patrick for the reftable writer]

quoted

The question is which call is bad? The cruft stuff is relatively
new and I don't know the code.

quoted

quoted

reftable/writer.c:              int n = w->write(w->write_arg,

zeroed,

quoted

quoted

quoted

quoted

quoted

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):

quoted

static ssize_t reftable_fd_write(void *arg, const void *data, size_t sz)

{

quoted

quoted

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.