"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
> Christian Holtje <docwhat@xxxxxxxxx> wrote:
>> I have read all the threads on git having trouble with pread() and I
>> didn't see anything to help.
> ...
>> Receiving objects: 100% (253/253), 5.27 MiB | 9136 KiB/s, done.
>> fatal: cannot pread pack file: No such file or directory
>> fatal: index-pack failed
>>
>> The end of the strace looks like so:
>> pread(3, "", 205, 1373) = 0
>> write(2, "fatal: cannot pread pack file: N"..., 57) = 57
>
> Hmmph. So pread for a length of 205 can return 0 on NFS? Is this
> a transient error? If so, perhaps a patch like this might help:
>
> diff --git a/index-pack.c b/index-pack.c
> index 5ac91ba..737f757 100644
> --- a/index-pack.c
> +++ b/index-pack.c
> @@ -309,14 +309,19 @@ static void *get_data_from_pack(struct object_entry *obj)
> unsigned char *src, *data;
> z_stream stream;
> int st;
> + int attempts = 0;
>
> src = xmalloc(len);
> data = src;
> do {
> ssize_t n = pread(pack_fd, data + rdy, len - rdy, from + rdy);
> - if (n <= 0)
> + if (n <= 0) {
> + if (n == 0 && ++attempts < 10)
> + continue;
> die("cannot pread pack file: %s", strerror(errno));
> + }
> rdy += n;
> + attempts = 0;
> } while (rdy < len);
> data = xmalloc(obj->size);
> memset(&stream, 0, sizeof(stream));
>
>
> The file shouldn't be short unless someone truncated it, or there
> is a bug in index-pack. Neither is very likely, but I don't think
> we would want to retry pread'ing the same block forever.
I don't think we would want to retry even once. Return value of 0 from
pread is defined to be an EOF, isn't it?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
