Subject: [netatalk-admins] Netatalk resource fork format

From: [email-masked] (Lee Blevins)
Date: Mon, 11 Jan 1999 07:15:28 -0500

I'm very dissapointed that in upgrading my Rampage rips
(www.rampageinc.com) they said I can't use netatalk or they won't
support the installation. 

EVen though I have a netatalk server working with their system and it's
showing no signs of instability.

Their network guru, Pat Flaherty, says that they've never heard of
freebsd or netatalk. The only issue he could flag as we discussed this
was that they need to read fonts off the server. They use an NT based
RIP and he says they don't know how the resource fork is stored and this
could be a problem. He also says that netatalk and freebsd have no
support base so he's worried about how they get support with it.

I would very much like to encourage Rampage Systems to add netatalk to
their list of supported servers. Currently they support a list of
servers that include NT, Sun and SGI. On their web page they don't say
what AFP's they support on Sun and SGI.

My question is how is the resource fork handled on netatalk relative to
other systems such as Ushare, Helios and NT's SFM? Is it something
completely different or is it the same?

---

From: Kadinger Andras <[email-masked]>
Date: Thu, 14 Jan 1999 03:31:56 +0100 (CET)

Hello Lee,

> support the installation. 

Hmm, I hope they have purely technical reasons.

> support base so he's worried about how they get support with it.

Hmm, for what it's worth, I've wrapped up a small unix utility to read
Type1 font definitions directly from PC and (netatalk formatted) Mac files
as a part of the OPI/Document Management subsystem. I created that about
four months ago but I hear Adrian is about to reorganize netatalk's
AppleDouble handling, so my utility might require some modifications to
work with the current version. Part of this utility were resource fork
handling routines (they are currently read-only and not very clean
though), so if that helps you... 

> what AFP's they support on Sun and SGI.

Hmm, if they are reading over AFP over the network, I think there should
be no differences in resource fork handling between correctly
implemented AFP servers. This also means there should be no difference
between netatalk and other servers in general - and as you previously
indicated, you indeed experience no problems in this respect.

> completely different or is it the same?

The resource fork itself is a Mac-specific data structure, so unless the
server software writers really wanted to show their technical
excellence/expertise, the resource fork itself should be in the same
format; however there are some 'meta' information of Mac files like
creation/modification dates, icons, type/creator codes, etc. which most
probably _are_ handled differently in each product. netatalk e.g. stores
this information in a secondary file in the .AppleDouble directory
together with the actual resource fork in one particular format; ushare
has them in the .rsrc directory also together with the resource fork, in
another, slightly different format: in both cases there is a (I think
fixed-size) header, followed by the actual resource fork data.

But this difference should only be visible on the server side, and should
not be visible over the network when accessed through AFP calls, so I
really can not see the technical reason of them calling this a
possible problem. Perhaps I oversee something? 

Hope, this helps,

Regards,
Andras Kadinger
[email-masked]

---

From: Mark Donnelly <[email-masked]>
Date: Thu, 14 Jan 1999 08:09:39 -0600

On Thu, 14 Jan 1999, Kadinger Andras wrote:

> netatalk e.g. stores
> another, slightly different format

I'm giving a presentation to a UNIX users group next Wednesday covering
filesharing to Mac boxen (netatalk) and Wintel boxen (SAMBA).  On the
issue of AppleSharing, there is at least one installation I know of that's
looking to move from an older K-AShare that came with IRIX
(.HSResource/.HSancillary, and a horrible product in my opinion) to
Adrian's ASIP netatalk on a NFS'd Linux/FreeBSD server.

Is there any sort of conversion utility that anybody has come up with to
go from .HS* to .AppleDouble?  Or from .rsrc (ushare) to .AppleDouble? For
these people, I think that conversion is going to be a fairly major thing.

Also, I know it's been brought up really recently, but I deleted it...
Could anyone doing work on SAMBA/netatalk integration email me about it
off-list?  Also, Wes, Adrian, could I get "from the horse's mouth" what
the status of your work is, and what your roadmap for the future is?  
When I'm through I'll make my presentation available on-line.

Thanks all,
--Mark Donnelly

---

From: Dejan Ilic <[email-masked]>
Date: Thu, 14 Jan 1999 16:38:53 +0100 (MET)

> these people, I think that conversion is going to be a fairly major thing.

I'm looking into the possibility to do the same, and probably make
support for the KaShare/Samba support meanwile.

I contacted Xinet (producer of KaShare) and they told me that the
structure .HSancillary i properiaty information and that they won't
release it.

Dejan
=====================================================================
Dejan Ilic, Tech Univ. of Linkoping, Sweden    Phone:+46-13-473 01 06
Email: [email-masked]   Web: http://www.lysator.liu.se/~svedja
=====================================================================
[finger -l [email-masked] for public PGP key]

---

From: Mark Donnelly <[email-masked]>
Date: Thu, 14 Jan 1999 10:17:15 -0600

> (.HSResource/.HSancillary, and a horrible product in my opinion) to

OK, I'm going to apologize and withdraw this statement right now.  This
was uncalled for on my part, as has been pointed out to me.  I had a bad
experience as an end-user (and a power user at that) of K-AShare, which
I've found out isn't necessarily all that common.  Esp. from the sysadmin
point of view, K-AShare is very nice.

As for the conversion facility, Lasse Hilleroe Petersen has pointed out
that the K-AShare utility karc has a -D option that puts things out in
standard AppleDouble format.  Whoohoo!

That solves that particular conversion.  Anybody else have any conversion
methods?  ushare?  CAP?  Ethershare?  I've already gotten a bit of an
smb.conf file that vetos appletalk internal files - is there anything else
to the integration, at this point?

Thanks all,
--Mark