Subject: Re: CAP to netatalk migration tools
From: Jonathan Paisley (jonp@chem.gla.ac.uk)
Date: Tue May 16 2000 - 12:08:32 EDT
On Wed, 26 Apr 2000, Jim Prall wrote:
> 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
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'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.)
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).
> 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.
Yup, we left the CAP stuff around for a while after the changeover to
ensure that things were ok.
-- Jonathan Paisley jonp@chem.gla.ac.uk
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:30:44 EST