Subject: Re: [netatalk-admins] current netatalk plans

From: [email-masked]
Date: Mon, 16 Mar 98 20:19:54 PST

The same problem that prevents aliases from working is also causing your Eudora
troubles.  An alias stores a folder location by it's ID number not by it's name,
so it isn't really like a Unix symbolic link.  Generally when an application
remembers a folder it does the same thing, that is it stores the ID number and
not the name.  Since folder ID numbers are not fixed on afpd volumes, they
change for each new connection, so after a re-boot a remembered folder ID can
end up pointing to nowhere or to a different folder.

(An aside for the programmers: I see in the code that FNUMs for files are
derived from Unix inode numbers, so they are more or less fixed; why can't DIDs
for folders be derived from the inode numbers of directories?  Wouldn't that
solve the problem, or at least be a temporary fix until it can be done "right"?)

Hope this helps!

Bob Smith
Hammett & Edison, Inc.
[email-masked]

______________________________________________
Original message sent on Mon, Mar 16  4:31 AM by [email-masked] (John Sutton) :

To: [email-masked]
Re: [netatalk-admins] current netatalk plans
This business of "persistent file id's" (3a below) - could somebody please=
 explain what this means!  I'm pretty green about the MacOS file system but=
 after a number of horrifying episodes I'm beginning to think I need to find=
 out...  For example, I've tried to use aliases on the local fs pointing to=
 files on a netatalk volume.  It works OK some of the time but then=
 occasionally the alias ends up pointing at a completely different file!  I=
 had thought that an alias was a textual entity (i.e. a soft link in Unix=
 terms) but I'm clearly wrong.

My current problem is not (as far as I know) to do with aliases and I wonder=
 if this also is a victim of this "persistent file id's" deficiency in=
 netatalk?  (Is this to be counted as a deficiency?  Do other AFP=
 implementations on NT or NetWare for example have the same problem?). =
 Anyhow, my problem is as follows.  I use Eudora with the mailboxes on a=
 netatalk volume.  This works fine so far (touchwood :-) once I'd realised=
 that I have to put the whole Eudora folder on the netatalk volume and not=
 simply keep it on the local volume with aliases therein pointing to the=
 real mailbox files.  However, if I try within the Eudora Settings to=
 specify that the Email Enclosures folder is also over on the netatalk=
 volume, this works some of the time.  But occasionally, when I start up=
 Eudora, it complains that the Email Enclosures folder does not exist. =
 Well, it does exist but the link has clearly been broken.  I suppose this=
 comes down to how an application (Eudora in this instance) stores the=
 reference to a folder which it is supposed to be using?

Am I on the right track or is this a Eudora-specific problem?

---

From: [email-masked]
Date: Tue, 17 Mar 1998 01:27:36 -0500

> From:    [email-masked]

> (An aside for the programmers: I see in the code that FNUMs for files
> are derived from Unix inode numbers, so they are more or less fixed;
> why can't DIDs for folders be derived from the inode numbers of
> directories?  Wouldn't that solve the problem, or at least be a
> temporary fix until it can be done "right"?)

The Mac implementation allows us to return FNUMs that are unique only
in the given directory, i.e. the inode number.  Since the inode number
of the root of any given mounted directory is 2, it's not practical to
use inode numbers for DIDs -- in /, say, /usr and /var could both be
DID 2.

I believe that a correct implementation must save the DIDs and FNUMs as
part of the Desktop.  A system that uses a separate daemon, a la AUFS,
won't work very well in a network file system like NFS or AFS.
However, the system must be robust enough to allow both writable and
read-only version of the database.  I think it's mostly just a lot (a
*lot*) of detail work, once it's all spec-ed out.

:wes