Re: port-evbmips/48564 ('tar' on evbmips-mips64el (LOONGSON) corrupts files extracted to NFS)

["John D. Baker" <jdbaker%mylinuxisp.com@localhost>]

The following reply was made to PR port-evbmips/48564; it has been noted by GNATS.

From: "John D. Baker" <jdbaker%mylinuxisp.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-evbmips/48564 ('tar' on evbmips-mips64el (LOONGSON) corrupts
 files extracted to NFS)
Date: Sun, 10 Jul 2016 17:47:05 -0500 (CDT)

 On Sun, 10 Jul 2016, dholland%NetBSD.org@localhost wrote:
 
 > State-Changed-Why:
 > no such luck.
 > 
 > I have a vague recollection that this problem (untarring to nfs) has been
 > seen before and not on mips.
 
 I think its mentioned earlier in the PR, but perhaps I should reiterate
 that the same type of corruption occurs when writing large files via
 redirection of STDOUT, e.g.:
 
   $ cat /etc/services > /path/to/nfs/services-cat
 
 but copying with 'tar' pipeline vs 'cat' do not produce identically-broken
 target files.  They start out the same, but at some point the 'cat' copy
 and the 'tar' copy get out of phase.  They don't stay out of phase though.
 A cursory examination seems to indicate that the 'cat' copy gets three 8KB
 blocks of 00 bytes written in succession at some point and picks up with
 the corresponding next block of file data.
 
 They both still produce target files of identical size, reflecting the
 size of the source file truncated to the nearest multiple of 8192 bytes.
 
 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645