Subject: Re: [netatalk-admins] installation question: Solaris 7

From: John Browning <[email-masked]>
Date: Thu, 18 Mar 1999 21:16:56 +0000

Many thanks for many responses to my query on installing netatalk. So far I've been asked/told

what version: netatalk-990130 from src.doc.ic.ac.uk (a Sunsite), compiled with gcc 2.8.1

is my Solaris 7 64-bit: yes

did I change services/netconfig: yes

am I using the asun version: no, but I will try that.

Thanks again.

John Browning   |||   71 Richmond Ave   |||   London N1 0LX
t + 44 171 700 1230      |||      f + 44 171 700 5255

---

From: Yuji Shinozaki <[email-masked]>
Date: Thu, 18 Mar 1999 19:44:35 -0500 (EST)

server: Sun Sparc 5 / SunOS 2.5.1 / netatalk-2.1.1
clients: MacOS 8.1 via Appleshare 3.8.1 (using ASIP)

I have run into a strange problem copying files from a netatalk volume:

We use RevRdist to maintain our clusters.  I recently moved the source
volumes from an Appleshare 4.2.1 server to our netatalk server, to take
advantage of ASIP.  The performance increase was astounding. [ A detail
that I should point out which may or may not be significant is that
RevRDist will normally mount things via AFP every time, so to "force" it
to use ASIP I use an applescript "wrapper" to do the ASIP mount and then
run RevRDist ].

However, we ran into a problem which I can only attribute to file
corruption:  Certain programs (specifically Labview 4.x and Mathematica
3.0.1) are adversely affected by being copied from the netatalk volume. 
In the case of Labview 4, specific Labview libraries don't ever load, and
in the case of Mathematica 3.0.1 the mathkernel always reports an "Out of
Memory" error.  Using the EXACT set of source files on our old AS 4.2.1
via AFP (since it cannot do ASIP) works fine. 

Further evidence: if I copy the installer disks to a netatalk volume,
and do an install from the ASIP mounted volume, it exhibits the exact 
same problem (so now RevRDist is out of the equation), BUT when I put the
installer on a volume mounted on our newly-acquired ASIP6.1 server, the 
installation works fine.

It would appear that even the installer files are getting corrupted either
on copying to or from the netatalk volume. 

[ It just occurred to me that I am not sure whether I have tried the
installation using netatalk via AFP. Perhaps that might tell me if the
assumed occurs in transport or storage.  Maybe something for me to
investigate. ]

My questions:

1) Has anyone noticed similar behavior?	Anyone know what the
problem/solution is?

2) Does anyone know of a mac application that does bitwise compares or
file checksums, so that I can pinpoint the file/s that are getting
corrupted.

3) Anyone have a suggestion for debuggin this problem?  Perhaps I might
try a newer version of netatalk.  Wasn't there a change in the way the
AppleDouble info is stored recently?

Thanks for your time and sage advice...
yuji
----
Yuji Shinozaki		        Systems Administrator
[email-masked]	        Dept of Physics and Astronomy
http://www.physics.unc.edu      Univ. of North Carolina - CH
(919)962-7214 (voice)           CB 3255 Philips Hall
(919)962-0480 (fax)	        Chapel Hill, NC  27599

---

From: Bob Krzaczek <[email-masked]>
Date: Thu, 18 Mar 1999 20:20:51 -0500 (EST)

On Thu, 18 Mar 1999, Yuji Shinozaki wrote:
; I have run into a strange problem copying files from a netatalk volume:

You didn't mention this, so I'll ask the easy question first ;-) If you've
already been through all this, my apologies.

Have you disabled CRLF translation for those files?

If not, there are two ways to go about it.

The easy way is to rebuild afpd with CRLF *undefined*. Check your Makefile
in SRCDIR/etc/afpd and kill the "-DCRLF". Follow this up with a "make
clean all". Reinstall "afpd", restart, and see if the problem goes away.
(Bear in mind, those files are likely still corrupted from the previous
afpd, so you should start with all new and "fresh" files).

The alternative is to determine the creator and type information for all
those files, and hope that "type" isn't being set to "TEXT". If it is, all
bets are off and you better go back to the easy solution. If their types
are all something other than "TEXT", check your "AppleVolumes.system" file
and ensure that default translation of CRLF data in unknown type files by
afpd is disabled.

There are still pitfalls with the second method (including the possibility
for this error to jump up and bite you again in the future), that make me
really really urge you to just recompile with CRLF disabled unless you
really really need it. ;-) (And besides, if even one of those corrupted
files is marked "TEXT", you're hosed anyway, since afpd is going to do its
honest best to treat it like a real text file, which will probably lead to
the corruption you're seeing).

(btw: just ask an admin of a netatalk box that serves Quark users how she
feels about CRLF translation. ;-)

Good luck,

// bob

-- 
// Bob Krzaczek, RIT Center for Imaging Science, <[email-masked]>

---

From: Palle Girgensohn <[email-masked]>
Date: Fri, 19 Mar 1999 03:44:41 +0100

Hi!

did you remove the cr/lf conversion? if the files are defined as TEXT,
it will get you into trouble. 

/Palle