Subject: Re: AppleDouble/Resource Forks....

From: "Tom Watson" <[email-masked]>
Date: Tue, 22 Aug 2000 02:54:27 -0800

On Tue, 22 Aug 2000 05:12:41 -0400 (EDT), [email-masked] wrote:
> I was thinking about the resource fork situation on the Mac, and the
> apparent need for AppleDouble directories on netatalk - or is there?
> 
<<<deletia>>>
> 
> Thus, you'd have:
> 
>  +--------+-----------------+---------------------+
> <| header | xx data fork xx | ** resource fork ** |>
>  +--------+-----------------+---------------------+

What you have here is called (TaDa) AppleSingle format!!

<<<deletia>>>
> 
> Of course, I'm sure I overlooked something - so, what are the drawbacks to
> this suggestion?

The thing is that other operating system(s) use the data fork of the file
as their only structure.  They desire to have the name associated with just
the data fork and handle the data there.  They don't really need the
information in the resource fork.  So, when they access the file they need
to fudge their way down the file using the header, and unless the underlying
operating system does it automatically (none do) they can't use the file
in the "combined" (AppleSingle) form.  The same applies in the reverse
direction.  A PeeCee writing a text file won't have the proper headers to
be read on the Apple Side.   OOOPS.

Even Apple when writing (or modifying) PC format floppies (and I think
things like Zip Disks) uses a method similar to AppleDouble in storing
resource fork data.  Format a DOS compatable floppy, then plunk it
into a DOS box and use a utility that will show all the "hidden" files.
There you will find the resource fork data.

> Harry

Of course, if one desires to keep things consistant, the AppleDouble part
of the file (having finder information, and resource fork data) could
include the inode number of the original file.  If the two don't jive
due to modification or other such stuff, the Double part could be deleted.

In any event the AppleDouble part of the file is VERY necessary, in its
form.
-- 
Tom Watson         Generic short signature
[email-masked]     (I'm at home now)

---

From: Mike Johnson <[email-masked]>
Date: Wed, 23 Aug 2000 12:16:55 -0700

Forgot to send it everybody....

-----Original Message-----
From: 	Mike Johnson  
Sent:	Wednesday, August 23, 2000 12:00 PM
To:	'Rasca Gmelch'
Subject:	RE: AppleDouble/Resource Forks....

For what it is worth, I agree!
I think the current solution is very stable. The only drawback I see is in
user friendliness. In a mixed environment, PC users accessing through samba
can see the .AppleDouble files. And system administrators may wonder what
the heck they are and go hunting for somebody to ask (like I did after first
using Netatalk).
Not a big deal unless somebody tries to remove one. My solution was to hide
the dot files from samba users, but my samba installation flat-out refuses
to do so. A question meant for samba maybe?
Is there a really great reason for changing it?
Anyway, I've not been on this list for too long, but I have read about
several problems - few ever doing with the resource forks. They seem to work
very well. I wouldn't be too enthusiastic about wandering further into the
outdated resource fork world. (Apple seems to be working on ridding
themselves of the unreliable system, anyhow. Why should Netatalk go the
other route?)
I think working to improve the client / server interaction is always a good
idea. Users will provide a never-ending series of ways to break any program,
and protecting against those problems (as well as working on the overall
speed and CPU usage) will always be a good place to find a more than amble
work load.
Another idea: maybe a good GUI configuration tool. Something like that will
help instill more confidence in the program. I, for instance, blush with
excitement whenever I find one. GUI means no silly typos in the conf files
and the insurance of a point and click service editor. I read somewhere that
a vast majority of Linux beginners give up because of the weak user
interface. Though Netatalk users are probably not Linux beginners, I'd bet a
good deal of money that many of them give up on programs that are difficult
to maintain, opting for something that takes less head scratching.
I know a GUI exists for Netatalk, but I've had problems with it and it is
not especially powerful. Not to mention, the new version that was supposedly
going to find my conf files failed on the install and I had to edit the
script. :-(
For what it's worth, that's my take on the subject.
- Mike Johnson
www.lunar.com
-----Original Message-----
From:	Rasca Gmelch [mailto:[email-masked]] 
Sent:	Wednesday, August 23, 2000 10:15 AM
To:	Harry Zink/Netatalk List; [email-masked]
Subject:	Re: AppleDouble/Resource Forks....

hi harry,

Harry Zink/Netatalk List wrote:
> 
> on 8/22/00 2:18 AM, Rasca Gmelch at [email-masked] wrote:
> 
> > and then you can't access the files in the normal way under the
> > unix/linux system - i mean the data fork! :-(
> 
> Okay, so such a header would interfere with a standard *nix reading these
> files. While this is irrelevant for application files, since they are of
no
> use natively anyways, this could be a slight issue with data files (again,
> if you are using the device uniquely and solely as an appltealk file
server,
> I don't see much need to ever need to 'use' the files in the traditional
> way. Only way I can see is to natively copy a file, in which the single
file
> format again would be of benefit.

we use netatalk in a mixured network (linux,nt,macos).. so the file
itself doesn't have more than the data fork it self.

> Now, I understand that the header, thus, is bad - how about just placing
> this information at the very end of the file? That way, no garbage at the
> end; the fs knows where the end of the file is, netatalk could just look
> there, in a designated place, and grab the same information.
> 
> Any drawbacks to that?

i don't see more drawbacks to stay on the current solution with
the .AppleDouble files.. i would improve the server / daemon
software and wouldn't change the current concept. here we
would loose time to find a stable solution.. imho.

cu
rasca

-- 
Triad Berlin Projektgesellschaft mbH * Marburger Str. 3 * D-10789 Berlin
Fon +49 (0)30 219098-69 * Fax +49 (0)30 219098-61 * http://www.triad.de/
.____________/\ Triad Berlin: Culture Media Environment /\_____________.

---

From: Michalowski Thierry <[email-masked]>
Date: Thu, 24 Aug 2000 09:03:21 +0200

Hi,
for what it is worth, here is an excerpt of my smb.conf file for Samba to
deal with the "apple" files on my Debian server.
So far I had no problem with it.
<excerpt smb.conf>
	delete veto files = Yes
      veto files = /.AppleDouble/.bin/.AppleDesktop/Network Trash Folder/
      hide files = /.AppleDouble/.bin/.AppleDesktop/Network Trash Folder/
</excerpt>

HTH
Thierry Michalowski

-----Original Message-----
From: 	Mike Johnson  

The only drawback I see is in