Subject: Re: Netatalk corrupts files and file size wrong on alpha
To: None <port-alpha@netbsd.org>
From: Michael G. Schabert <mikeride@mac.com>
List: port-alpha
Date: 04/24/2003 19:08:27
>On Tue, 22 Apr 2003, John Refling wrote:
>
>>  Anyone using netatalk on alpha successfully?
>
>Maybe not, judging from the lack of response.
>
>>  Each time I transfer a file to the mac volume served
>>  by the alpha's netatalk server, the file is corrupt.
>>  The first part of the file will be OK, then garbage.
>>
>>  Additionally, a 50k file on the mac will have a file
>>  size of over 500MB on the Netbsd side, per ls, but
>>  that disk space does not seem to be accounted for by
>>  du.
>>
>>  How can this be?
>
>It's a "sparse" file? When you seek() past the end of file, the file
>grows, but the intervening bits of the file are not really there, so
>no space is taken up on the disk. I'm pretty sure that reading back
>those parts is supposed to returns 0x00's, though, not garbage.
>
>"netatalk-asun" is an ancient (and therefore widely used) version of
>the code-base for the current netatalk package. You might give that a
>try, to help narrow things down. Either way, it sounds like a
>significant bug, so please file a problem report.

I had reported similar NetAtalk results a couple months ago, but I 
failed to do comprehensive testing and reporting (i.e. AppleTalk vs 
TCP on my various Macs, which direction, etc), since my BSD machine 
was in a state of flux. I noticed the problem because I was using my 
Mac to download pkgsrc distfiles on an AOL dialup overnight, and have 
since returned to having a "normal" connection which I can have my 
BSD machine NAT, so my dealings with the issue have subsided. I can 
say, however, that running the asun version "fixes" it so that 
everything works fine, and I still have the issue when using 
netatalk-1.6.1 and userland/kernel from -current sources March 22.

The copy seems to work fine when copying from the BSD machine to the 
Mac. The folder on the Mac HFS+ filesystem is about the same size as 
the source folder. I then rename the folder for the return trip & 
copy it back. At this time, the copy craps out partway through, and 
the folder is now Gigs large (~100MB source) according to the 
"calculate folder sizes" in the Mac finder.

Mike
-- 
Bikers don't *DO* taglines.