Subject: [netatalk-admins] Netatalk-1.4b2-hurricane & corrupted mp3s and quicktimes

From: mt71310 <[email-masked]>
Date: Tue, 14 Apr 1998 14:25:06 -0700

I've been using 1.4b2 Hurricane in my schoolroom lab providing file
services to 32 macs.  Things seem to work just fine, except that a
student recently discovered that his mp3s and quicktimes seemed to have
acquired sharp crackling audio distortion and white speckled videio
artifcacts after transferring to/from the Linux box via Netatalk.  The
corruption stayed with the file after the transfer.

Clean files transfered to the same box via ftp showed no similar
corruption.

Is anyone else experiencing this?  Can anyone help me?  I thought it
might be specific to the one box, but tried it on another model and
found the same results.

Could netatalk be misinterpreting quicktime binaries and mp3s for some
sort of text and adding/removing cr/lfs or something...(I'm obviously
shooting in the dark here)

Any help would be greatly appreciated.  It's heartbreaking to find such
a fly in the ointment.

Marc Turnbow

---

From: Jonathan Peterson <[email-masked]>
Date: Wed, 15 Apr 1998 09:54:02 +0100

>shooting in the dark here)

And hitting the target. This is probably what is happening. There are two
solutions that I am aware of:

1. Re-compile without CRLF transation enabled. You'll have to scour the
readme's to find where it is that this needs to be commented out. I seem to
remember it being slightly unobvious. This disables ALL CRLF transation,
for text files too.

2. Add entries to AppleVolumes.system and AppleVolumes.default to make sure
it knows they are binary files.

--------
Jon Peterson	[email-masked]	+44 (0)171 613 5300

"Behold the duck, it does not cluck,
A cluck it lacks. It quacks."

---

From: Osma Ahvenlampi <[email-masked]>
Date: 15 Apr 1998 12:13:49 +0300

> I've been using 1.4b2 Hurricane in my schoolroom lab providing file

Hurricane? That's a codename I haven't heard before (well, except that
Red Hat Linux 5.0 is codenamed Hurricane).

> corruption stayed with the file after the transfer.
[..]
> shooting in the dark here)

Shot in the dark maybe, but exactly correct anyway. Netatalk compiled
with the default options will 1) assume any file with an extension it
doesn't recognise is type TEXT/UNIX 2) perform CR/LF translation on
all files of type TEXT.

Quick fix: add the extensions to AppleVolumes.system with the correct
type/creator codes (or at least codes other than TEXT).

Get rid of the problem itself: recompile Netatalk (afpd) without
-DCRLF. It's nothing but problems anyway, text editors can deal with
linefeed differences by themselves if they're any good.

-- 
A conclusion is simply the place where you got tired of thinking. 
Osma Ahvenlampi <[email-masked]>

---

From: Vivek <[email-masked]>
Date: Wed, 15 Apr 1998 10:22:58 +0100 (BST)

> it knows they are binary files.

Something I find useful is to make the default translation BINA/UNIX,
which means that CR/LF translation only occurs if the Mac sets the type as
TEXT or the default type in AppleVolumes.system is explicitly set to TEXT.
That way when you mistranslate, or rather fail to translate, you err on
the side of caution.

--
fsck -f -b 8193 /dev/cortex

---

From: Andras Kadinger <[email-masked]>
Date: Fri, 17 Apr 1998 01:03:22 +0200

I wonder, what would happen, if instead changing all CR-s to LF-s in one
direction, and changing all LF-s to CR-s in the other, we would exchange
CR-s with LF-s in both directions; this way, even with a translated
file, You get the correct and unaltered binary contents back if You read
it on a Mac.

An actual translate-on-disk subroutine for the case the TYPE later gets
changed from TEXT to something else might also be considered - this way,
even the not so 'clever' MS Word* would work with translation on.

What we would lose is having mixed end-of-line files appear nicely as
LF-only on the unix side, and get back CR-only to the Mac side.

In fact, I thought netatalk was swapping CR-s and LF-s, and I only
recently checked the source to see it behaves differently.

* - [For the ones who doesn't know this yet.] MS Word types it's files a
TEXT first, the writes the contents, and subsequently changes the file
type to the real one; using the old netatalk CR/LF translation the file
would be irrevokably corrupted; with the new one, netatalk would only
have to translate it again to recover the original contents.

Sincerely,
Andras Kadinger
[email-masked]

PS: I made up a patch which should change the behaviour to the one I
prefer.
The changes are obvious, but I did not actually test this. If people
would try it out and find it beneficial, Adrian could include it in his
next patch set.

Here it is:

--- etc/afpd/Makefile.orig      Fri Apr 17 00:53:13 1998
+++ etc/afpd/Makefile   Fri Apr 17 00:54:23 1998
@@ -14,7 +14,7 @@
 INCPATH=       -I../../include ${AFSINCPATH} ${KRBINCPATH}
${DESINCPATH} \
        ${PAMINCPATH}
 CFLAGS=        ${DEFS} ${AFSDEFS} ${KRBDEFS} ${DESDEFS} ${OPTOPTS}
${INCPATH} \
-       ${PAMDEFS} -DAPPLCNAME -DCRLF # -DDOWNCASE
+       ${PAMDEFS} -DAPPLCNAME -DCRLF -DCRLFTWOWAY # -DDOWNCASE
 LIBS = -latalk ${AFSLIBS} ${KRBLIBS} ${DESLIBS} ${ADDLIBS} ${AFPLIBS} \
        ${TCPWRAPLIBS} ${PAMLIBS}
 LIBDIRS=       -L../../libatalk ${AFSLIBDIRS} ${KRBLIBDIRS} \
--- etc/afpd/fork.c.orig        Fri Apr 17 00:27:27 1998
+++ etc/afpd/fork.c     Fri Apr 17 00:55:17 1998
@@ -471,6 +471,11 @@
            if ( *p == '\012' ) {
                *p = '\015';
            }
+#ifdef CRLFTWOWAY
+           else if ( *p == '\015' ) {
+               *p = '\012';
+           }
+#endif
        }
     }
 #endif CRLF
@@ -743,6 +748,11 @@
            if ( *p == '\015' ) {
                *p = '\012';
            }
+#ifdef CRLFTWOWAY
+           else if ( *p == '\012' ) {
+               *p = '\015';
+           }
+#endif
        }
     }
 #endif CRLF