doesn't seem to handle this possibility.
Attached are two patches, the first replaces the safe_read call in
blocking_read with
full_read from gnulib, I have verified that this change fixes the bug.
I can't seem to understand what's the point of distinguishing between
safe_{read,write} an
Seems like this thread has stalled, thanks Dominique for responding to this.
I wasn't expecting to find the 9p maintainer on this list and the resulting
conversation really helped me understand the nuances of the issue much better.
On 30/07, Paul Eggert wrote:
> > Well; I don't know. I'm open to d
On 04/08, Paul Eggert wrote:
> Simply switching from safe_read to full_read would lose an errno value if
> there's an I/O error, so that patch alone wouldn't suffice for GNU 'tar'.
Can you elaborate? I can't find a code path that loses the errno.
'full_read' breaks if safe_read returns an error (
[ As said requested in the original message, please keep me in Cc ]
On 05/08/2020, Paul Eggert wrote:
> On 8/5/20 11:47 AM, Nikos Tsipinakis wrote:
> > Can you elaborate? I can't find a code path that loses the errno.
>
> full_read reads a partial block and then tries to re
A small correction that I noticed a bit too late to fix in the previous
message: We
should also reset errno at the beginning of the call to ensure it's actually an
error.
>From 2aaeac922507d24820e38a4b6959cfa38d9da0c3 Mon Sep 17 00:00:00 2001
From: Nikos Tsipinakis
Date: Sat, 26 Sep 20
On 26/09, Andreas Dilger wrote:
> I think the proper behavior here is to return the bytes actually read, then
> retry the rest of the read. If there is a permanent error then it can be
> returned from the next read. It doesn't make sense to return an error
> if you don't have to...
That's the inte
