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

From: John Sutton <[email-masked]>
Date: Mon, 16 Mar 1998 12:31:43 +0000

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?

At 14:25 12/03/98 -0800, a sun wrote:
>        3) i'll probably add stubs to afpd to talk to a file catalogue
>           daemon for lookup and updating directories. the catalog
>           daemon will probably take a little longer to actually
>           write. this should solve three problems of which i'm
>           aware:
>                a) we should be able to add in persistent file id's.
>                b) we should be able to tag filename lengths as short
>                   (11 mac chars), medium (31 mac chars), and long
>                   (255 unicode chars). this should help prepare afpd
>                   for long filename support. 
>                c) directory lookups should get faster.

***************************************************
John Sutton
SCL Computer Services
URL http://www.scl.co.uk/
Tel. +44 (0) 1239 621021
***************************************************

---

From: [email-masked]
Date: Fri, 20 Mar 98 19:18:41 PST

>> Do you think this will work if afpd volumes are set up so they never cross
Unix
>> filesystems?  That would guarantee the directory inode numbers are unique
within
>> a volume.  I don't have a problem with restricting volumes this way, I
already
>> have dedicated filesystems for the afpd volumes.  Obviously this would be a
>> site-specific "hack" and not a general solution, but it seems like it should
>> work for me.
>
>Might there be some way to put a major:minor or other filesystem
>identifier combined with the inode number in that field? This should be
>reasonably stable on a given machine even between afpd sessions.

I thought of that too, however the directory IDs (DID) and file IDs (FNUM) have
to co-exist so that DID < FNUM in all cases on a given volume.  The FNUMs are
already being computed as the file inode number with the device number shifted
into the high bits to guarantee they are > DIDs, which are assigned sequentially
starting with 3 and so are always relatively small.  The only way to use inode
numbers for DIDs without also changing the way FNUMs are computed is to make
sure the DIDs have the appropriate high bits zeroed so they are always smaller
than FNUMs

Actually, even with this idea the FNUM computation has to change slightly. 
Currently only the lower 16 bits of the inode number are used, with the device
number shifted into the upper 16 bits.  Even on relatively small filesystems
inode numbers can be > 65535, so to make sure DIDs stay unique, more bits of the
inode number have to be preserved in the FNUMs and DIDs.  How much depends on
the maximum possible inode number, which depends on the filesystem size, so a
particular number of bits is not going to work in all cases.

There may be some other scheme for deriving IDs from device/inode numbers with
the necessary properties of DID < FNUM and DID uniqueness even across
filesystems, but I think it would be really tough to come up with something that
works in every conceivable situation.  Wes is correct that the "right" solution
is to generate the IDs without dependence on the Unix filesystem, and store them
in a database somewhere.  But I'm looking for a short-term "hack" that will work
for me.

The devil is always in the details!

Bob