Subject: CAP to netatalk migration tools

From: Jim Prall <[email-masked]>
Date: Wed, 26 Apr 2000 11:56:34 -0400

We have a really large filesystem on Solaris 2.6 served by CAP 6 (pl.198)
We've been aware of netatalk for quite some time, and have in fact
run it on some smaller systems. Recently we've become really concerned
that CAP is not getting any further development. We installed the latest
netatalk +asun on a Solaris 2.6 system we're building up, and we really
liked the performance.

So now we're in the position of needing a plan for migrating our huge
filesystem from CAP to netatalk. This is a busy production system, with
about 200 Gb in use out of 260 Gb available. There is just no way this
is going to get duplicated by dragging files with a Mac. Our intention
is to use unix scripts to walk through all the directories, creating the
required .AppleDouble subdirectory, then populating it with the
correct netatalk-format files derived from info in the existing CAP
.finderinfo and .resource files. We've got a rough idea of what's
involved in writing a tool to do this, but we'd love to discover that
someone else has this written already - however rough. We don't
need a fancy polished tool and we can expand on any pieces that might
be floating around. Can anyone point us toward such a tool, or the
particular details we'll need to treat to write one? We're aware of
the netatalk utility "megatron" but this appears to be targeted at
AppleDouble<->AppleSingle<->BinHex/MacBinary, which all involve
copying the data fork. We really want to avoid touching the data forks,
as (a) many of these are really large and (b) we need to keep file dates
intact. If we change file mod dates, our QuarkXPress jobs on Macintosh
will decide that every art file placed in every publication has been "modified"
and will thus make us sit and wait, and wait, while Quark re-imports all
the picture previews. Ouch.

We've noted with pleasure that netatalk appears to follow the same rule
as in CAP for encoding unix-illegal characters in mac filenames, viz. expanding
them to colon followed by two hex digits. Is anyone aware of any deviation
between netatalk and CAP on, e.g. which exact set of characters are so encoded?
(We'll burrow into the source if nobody has this nailed down already.)

We can do the migration while the filesystem is quiet over a weekend. I
suspect
there would be space enough to leave the CAP pieces behind until we can confirm
that the netatalk conversion is a success - typically the PICT preview at
72 dpi
is the bulk of the resource fork data, and these files tend to have 300 dpi or
higher in the data fork, so resources should be no more than 6% of the disk
usage.

Finally, we had the impression from earlier experiments that it is not safe to
try to run two different Appletalk stacks off the same Solaris box, such as
having both CAP and netatalk running at once. Can anyone confirm if this
is truly verboten, or if there is a way to do it safely? If it could be done,
we would be able to publish a different sub-directory of the big RAID
filesystem
as a netatalk volume, and gradually migrate new work into there as we
gradually migrate off the CAP sub-directory. (We would not try to serve
the same directory with both services, just different locations.)

------
--    Jim Prall      jimp AT gandalfgraphics.com
--    Gandalf Graphics Limited
--    260 Bartley Drive, Toronto, ON Canada M4A 1G5
--    416-750-2324

---

From: Tom Fitzgerald <[email-masked]>
Date: Wed, 26 Apr 2000 14:51:04 -0400

> is truly verboten, or if there is a way to do it safely?

I'm running both CAP and netatalk stacks on a single system here... (CAP
for printing, netatalk for file services).  It has worked fine for a year.
I wouldn't rule out running both file services on one machine.  The
two stacks just aquire different net/node addresses.

I experimented with running netatalk locally and CAP on a little machine
with all the disk NFS-mounted from the system running netatalk, and that
worked also - but didn't seem to be worth the trouble.

---

From: Howard Schultens <[email-masked]>
Date: Thu, 27 Apr 2000 11:36:47 +0200

> two stacks just aquire different net/node addresses.

Could you post your configurations for CAP and Netatalk? (atalk.conf,
etc.)?  What are the advantages of using CAP for printing rather
than Netatalk?

Thanks,

-- Howard
 
--------------------------------------------------------------------
Dipl.-Phys. H.Schultens     Tel: +49 551 39-5914
Zentrum Physiologie         FAX: +49 551 39-5923
Humboldtallee 23
37073 Goettingen       mailto:[email-masked]
Germany               http://www.neuro-physiol.med.uni-goettingen.de
--------------------------------------------------------------------

---

From: Jonathan Paisley <[email-masked]>
Date: Tue, 16 May 2000 17:08:32 +0100 (BST)

> particular details we'll need to treat to write one? We're aware of

I have written (and successfully used) such a tool on a CAP system that 
was running on Solaris. It's a C program and is reasonably fast.

The other useful program you might need is an app to rebuild the desktop 
database of the files once they have been converted (this is stored 
differently). I have also written a tool to do this. 

The latter tool is already available at

http://students.dcs.gla.ac.uk/students/paisleyj/netatalk/

If you're interested in the former program let me know and I'll look it out!

> (We'll burrow into the source if nobody has this nailed down already.)

I encountered this issue while doing the conversion and in the end I 
think I fiddled the rules in the afpd source slightly to coincide with 
CAP (can't remember right now and I don't have the sources handy).

> higher in the data fork, so resources should be no more than 6% of the disk

Yup, we left the CAP stuff around for a while after the changeover to 
ensure that things were ok.

-- 
Jonathan Paisley
[email-masked]