Netatalk --> Win2K SfM?


Subject: Netatalk --> Win2K SfM?
From: Andrew D. Myers (andrewm@imagegroup.com)
Date: Thu Jun 07 2001 - 15:26:33 EDT


Executive summary:

Does anyone know of a handy tool/technique for taking the resource fork
and attributes from an AppleDouble file and stitching 'em into the
corresponding NTFS data streams under Win2K Services for Macintosh?

More detailed situation:

I've got approximately 140GB of data on a samba/netatalk server
(netatalk 1.3.x, don't remember which revision, on linux 2.2.x), in tens
of thousands of files. I need to move 'em to a Win2K box w/Services for
Macintosh installed.

Here's the complicating factors: This server's been used by Mac, Linux,
and Windows folks. The Windows guys have oodles of filenames with >31
characters (which don't appear for the Mac folks), the Linux folks have,
in some cases, written out files which differ only by case (eg: foo.txt
and Foo.txt), and the Mac people 'round here love to use
windows-verboten characters like ? and : in their filenames.

I need to a) copy all the files with data/resource forks & file types
intact, and b) make all files visible to the Mac guys on the new server,
and c) use Win2K legal filenames (duh).

Here are the viable solutions I've come up with:

1. Write a perl script to crank through the exported shares on the
netatalk server which renames the files that will cause Windows fits
(ie, replace invalid chars with ~), and mangles names that are > 31
chars or differ only in case (foo vs. FOO). Then, once all the
filenames are in order, go do a drag'n'drop from one server to the other
on a Mac, and go home for the weekend.

2. Write a perl script to do similar as #1, but instead of renaming,
actually copy the files from the netatalk server to the Win2K box.

Problem with #1: I'm extremely cagey about turning a script loose on
140GB of valuable production data, even if it's only renaming stuff. If
at all possible, I'd like to leave the old server absolutely intact so
we can fall back if (when) we run into problems during the migration.

Problem with #2: I can't find an easy way to take the AppleDouble
information and put it into the appropriate NTFS file streams, short of
learning me the AppleDouble file format and writing a tool to do this
m'self. I've searched high and low for such a beastie, but have yet to
find one.

At this stage, it looks like I'm going to go with option #1 (after a
suitable backup).

Anyhow, apologies for the long-winded explanation (thus the summary up
front), and thanks for any suggestions.

--Andrew



This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:41 EDT