On Tue, Feb 27, 2024 at 09:10:55AM -0500, rsbecker@xxxxxxxxxxxxx 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.
Patrick
Attachment:
signature.asc
Description: PGP signature
