Subject: [netatalk-admins] I'm worried..

From: Tony Moran <[email-masked]>
Date: Tue, 20 Jan 1998 22:41:24 +0000

I've just got netatalk going fine and purring, and am about to bring
the Server on-line for the masses..well..all twenty of us anyway..
But, with a bit of talk recently on the list about Mac->Unix file translation,
I'm really worried about the prospect of files being mis-translated or
somehow corrupted.  Especially important graphics and database/spreadsheet
files..

What are the opinions and experiences out there ? - Do the default mappings
that come in AppleVolumes.system suffice to take care of everything to
satisfaction or have they caused problems for people..?

I also added in additional mappings that were supplied to the list from
last year,
hoping to cover as many file types as possible,  tho the users here tend not to
suffix files according to the file type - tending to rely on longish
descriptive
names instead.  I noticed that the new mappongs I took from the
list-posting used
completely new file typings, like GKON, R*CH, SCPL - was I wise to add these
into AppleVolumes.system ?

Many thanks for any advice, experiences or suggestions,

Tony.

__________________________________________________
Tony Moran			IT Manager
Ph:   (+353-1)-8303455		Scope Communications.
Fax: (+353-1)-8300888		http://www.infolive.ie
                                                        http://www.jobfinder.ie
      Ireland's online Jobs and IT resources Web Site - Check us out !
__________________________________________________
How to complain about Spam: http://weber.ucsd.edu/~pagre/spam.html

---

From: Bill Stewart-Cole <[email-masked]>
Date: Tue, 20 Jan 1998 16:52:56 -0600

>somehow corrupted.  Especially important graphics and database/spreadsheet

The ONLY way you risk that is if you have line-ending translation turned
on. IMHO it is a dangerous feature, and should not be turned on by anyone
who uses anything other than plain text files on the server.

>satisfaction or have they caused problems for people..?

The default mappings are too few for most people I would think. They are
not going to corrupt anything, they just might make file opening a bit of
as challenge.

>into AppleVolumes.system ?

Probably not, since those sound like my preferred mappings... :)

But seriously, The creator field is a lot less important than the type
field. Respectively those are GraphicConvertor, BBEdit, and SoundApp, all
of which are very nice programs in their own way, although none is likely
the most common tool for opening the files that they are capable of
opening.

The result of using a creator code that is 'wrong' for you is that
double-clicking the file will either open an application you don't want to
use for that type of file OR if you don't have that application, provide
ither a selection of applications capable of opening it (if  Easy Open is
installed) or an 'application not found' error. Getting the type wrong is a
bit worse since any program that looks at it will expect one format and
find another, and report the file is corrupted when in fact it is perfectly
fine for its REAL type.

----
Bill Stewart-Cole
This space for rent. Inquire within.

---

From: Scott Venier <[email-masked]>
Date: Tue, 20 Jan 1998 18:03:56 -0500 (EST)

The way I understand it, if all the files are created on a Mac, and just
saved to the netatalk volume, the AppleVolumes.system doesn't come into
play.  The Mac will save the file with the correct type and creator codes. 
The mappings are for files that got onto the drive in some other way
(created in unix, samba share to a pc, ftp, etc.) and don't have a
.AppleDouble entry associated with them.

Scott

> This space for rent. Inquire within.

=====================================================================
Scott Venier                      *ResComp Network Support Technician
[email-masked]                        *Consultant for Ingematics,
[email-masked]                     a division of Compu-Aid, Inc.
---------------------------------------------------------------------

---

From: Patrik Schindler <[email-masked]>
Date: Wed, 21 Jan 1998 00:00:47 +0100

>What are the opinions and experiences out there ?

I disabled File translation completely in afpd/Makefile (kick out -DCRLF). I never had any problems since then. And if must open textfiles, I use BBEdit on the Mac, which filters LFs and on Unix I have a small C-Pet (crlf, lfcr, dosify) which does the job if neccessary.

:wq! PoC(@pocnet.net)

---

From: Bill Stewart-Cole <[email-masked]>
Date: Tue, 20 Jan 1998 17:31:16 -0600

>.AppleDouble entry associated with them.

Yes. I guess I didn't make that clear.

If all you ever do with your netatalk-shared space is move files to and
from Macs via AFP, the AppleVolumes type/creator mappings serve no purpose.
They only get applied to files of mysterious and dubious origins (like Unix
and Wintel sources... )

----
Bill Stewart-Cole

---

From: David Kelly <[email-masked]>
Date: Tue, 20 Jan 1998 21:13:54 -0600

> satisfaction or have they caused problems for people..?

As others have said, if a Mac wrote the file to your netatalk server
then the Type and Creator fields will be correct and will remain
correct.

I'm trying to solve a different problem with my netatalk server than you
are. I'm receiving data via email on the FreeBSD system, reformating it,
then "posting" it to a public read-only directory for others to use. In
this case I want sane settings for .gz, .zip, and .txt, for files that
don't have a real Mac to create them.

Probably the most important thing you could do to ensure data integrity
is to hunt down the -DCRLF entry in afpd's Makefile and remove it! (then
recompile and install) Once -DCRLF is removed netatalk will never alter
the contents of a file. But with it, netatalk may take liberties on
files of type TEXT -- writes to HD replacing \r with \n's, serves to
Macs with \n's changed to \r's. That *could* be a nice feature but
sometimes it will burn you. Acrobat files are sometimes of type TEXT
when they are not really. Once the damage is done you can't repair the
file without guessing.

The other concern is that you don't want to lose the contents of
.AppleDouble/ as possibly half of your data is stored there. If a Mac
set the Type/Creator of a file on your server then that information is
in the .AppleDouble directory along with the file's resource fork.

Having scanned the past year's archive of this list today my head is 
rolling. There were a number of postings on reaping unneeded files from 
.AppleDouble/ as when somebody deletes the data-fork side from Unix the 
resource-fork side in .AppleDouble remains forever.

--
David Kelly N4HHE, [email-masked]
=====================================================================
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 20 Jan 1998 20:10:11 -0800 (PST)

> They only get applied to files of mysterious and dubious origins (like Unix

Unfortunatly it's not always so. A few programs will save a file first as
a 'TEXT' file, and then change its file type. Thus when it gets read, NO
translation gets done, and the file is read corrupted.

Though there's no good fix for this, one change might be to look and see
if a file's changing translation status when changing finder attributes,
and translate it on the fly if so, That way, it'll get read right.

If this idea gets implimented, it should be an option. :-)

Take care,

Bill