Frederick Bruckman wrote:

> In article <20041203005647.GA19366@panix.com>,
> 	tls@rek.tjls.com (Thor Lancelot Simon) writes:
> 
>>On Thu, Dec 02, 2004 at 07:08:39PM -0500, Louis Guillaume wrote:
>>
>>>I have a Netatalk Server on NetBSD. Macintosh users mount shared 
>>>directories and store files there.
> 
> 
>>>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?
> 
> 
> No doubt he is not. The netatalk package ships with a handful of utilities
> (apple_cp, apple_mv, apple_rm) whose very purpose is to make transparent
> the "hidden file" handling. Dumping or tarring up a whole directory should
> get them fine, though, without any help.
> 
> 
> Frederick


These utilities are great, thanks for that. And could easily be modified 
to accept other flags of cp, mv and rm (like the -p for preserving 
permissions on a cp).

What would be interesting to me is a way to, on the NetBSD machine, 
mount a remote AFP share, and have the files on that volume appear to 
the local machine with the resource forks split out into the 
.AppleDouble directory. Sort of like a reverse netatalk mapping.

This would enable remote backup of shared HFS+ filesystems on NetBSD. 
Also it could ease the copying from shared HFS+ to netatalk shares.

Just a crazy idea, but does anything do this?

I'm thinking of this because we contemplating moving away from Apple 
hardware and AppleFileServer to NetBSD and netatalk. The migration of 
data poses somewhat of a problem with the resource forks.

Louis