Subject: Re: [netatalk-admins] Netatalk resource fork format
From: Kadinger Andras (bandit@freeside.elte.hu)
Date: Wed Jan 13 1999 - 21:31:56 EST
Hello Lee,
On Mon, 11 Jan 1999, Lee Blevins wrote:
> 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.
Hmm, I hope they have purely technical reasons.
> 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.
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...
> 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.
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.
> 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?
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
bandit@freeside.elte.hu
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:11 EST