To clarify further:

netatalk uses the .AppleDouble folder in each directory to store all
the resource forks for the files in that directory. As long as your
backup scheme preserves those .AppleDouble directories, permissions
and all, you should be fine.

The one catch is that you have to present the restored files to the
mac using netatalk, which will automagically reunite the resource
forks with the data forks. If you just untar (or whatever) directly on
a mac, you'll get a big pile of uselessness.

Cheers,
-alex.


On Thu, 2 Dec 2004 19:56:47 -0500, Thor Lancelot Simon <tls@rek.tjls.com> wrote:
> On Thu, Dec 02, 2004 at 07:08:39PM -0500, Louis Guillaume wrote:
> 
> 
> > Hello,
> >
> > I have a Netatalk Server on NetBSD. Macintosh users mount shared
> > directories and store files there.
> >
> > There is the obvious issue with HFS+ metadata and resource forks.
> >
> > I've had a look at hfsutils, but that seems to be useful when you
> > actually have an HFS filesystem.
> >
> > Here we have a regular FFS filesystem, shared up over AFP. So we have
> > more than just the data forks stored on the FFS filesystem.
> >
> > dump, tar, cp et al destroy the resource forks, disassociating them with
> > the data forks.
> 
> That doesn't make any sense.  In an FFS filesystem there only *is* a
> "data fork"; the netatalk AFP server stores the resource fork in a
> separate file.  So it is certainly not the case that NetBSD's "dump, tar,
> cp et al" destroy the resource forks; the "resource forks" were never
> there to begin with.
> 
> Perhaps you are not copying the separate file that actually contains
> the resource fork?
> 
> Thor
>