Re: [Netatalk-admins] Re: [Netatalk-devel] File Compatibility

[Craig R. <cr...@po...>]

On Fri, 2004-04-30 at 09:11, Daniel Hazelbaker wrote:

> Ahh, yes my mistake.  It does use the alternate .rsrc format.  Either way,
> it is moving people away from HFS+ specific fork handling.

Amusingly, it seems other filesystems are moving to support
streams/forks and smart metadata storage. NTFS has had streams since ...
well, forever. Reiser4 looks like it should have nice support for
streams, too. Many filesystems support extended attributes that could be
used to store things like the mac type/creator codes. 

I don't see much chance of wider and more reliable support for this sort
of thing in mail clients, though, so no doubt 'fork' type problems and
the need for special "flattened" file formats will plague us forever.

Alas, I fully expect that as soon as apps start showing up that use
.rsrc files for resource forks, I'll get a lot of files emailed from
users ... that only contain the data fork file. *sigh*. This is one of
the reasons I love PDF - no more zero byte font files, no more unusable
Quark documents.

> I said "want them to die", not had already completely killed them.  Since
> you were so kind enough to remind me of the .rsrc confusion I had, take
> your own advice and have a look at a 10.3 install. grep / -name \*.rsrc. 

s/grep/find/
?

> Yes.  I was bored one day and wanted to see if it could be done.  It ran
> quite happily for a week under my normal heavy load before I got bored
> again and nuked it to put yellow dog on it.

I must say I know of people who have run OSX Server on UFS. They do have
a lot of problems with apps, but the OS seems to run quite fine. I don't
know about the client version, though.

> I don't recall anywhere in this thread where somebody has said it wasn't. 
> What they have been saying is we should try to be more compatible with the
> OS we are trying to reach, namely Mac OS X.  I have seen good suggestions
> met with "well we can't do that."

As this topic appears to have been covered before, it might be
informative to check out the archives.

My understanding is that, essentially, Apple's format is not designed to
give full functionality, only the minimum required to let Macs store
forked files on SMB volumes. Perhaps Apple would prefer that you buy an
XServe than use your existing Samba/*NIX or Win2k file server? 

As a result, there are a large set of issues that may include
performance, compatibility with older apps, aliases (CNID), and more. I
don't know enough to go into details, or know which are and are not
issues, but it's clear from discussion on this list that the OSX/SMB ._
files simply don't store the information NetATalk needs to have in order
to work as well as it does.

The NetATalk file format documentation might be informative.
http://users.phg-online.de/tk/netatalk/doc/Apple/

BTW, thanks Thomas for that info. I haven't had a chance to look at
doing much more with the importer yet, as I've just been landed with a
large in-house software development project. Because of the CNID issue
it's non-trivial to do correctly - I don't know when I'll have time to
look into it in detail. Right now my evenings are spent poring over code
that starts with 'COPYRIGHT 1983' in a dead primitive
"database"-integrated 4GL called Plain English. Fun, fun, fun.

Craig Ringer