Subject: Re: Mac Aliases changing

From: Evan P Cordes <[email-masked]>
Date: Wed, 25 Jun 1997 13:35:28 -0400

>From epcordes Wed Jun 25 04:52:06 1997
Subject: Re: Mac Aliases changing 
Date: Wed, 25 Jun 97 16:12:24 +0800
From: J=?ISO-8859-1?Q?=f6rg_Bullmann?= <[email-masked]>
To: <[email-masked]>, "Bill Studenmund" <[email-masked]>
cc: <[email-masked]>

>> I think one commercial package's solution was to just make an extra file
>> in the directory containing its folder id. Thus it'd be permanent.
>
>A better solution would be to place a single file at the root of the
>mounted volume containing, basically, the contents of afpd's directory

To have that information in a single file is not very handy in the =
long run. If you e.g. move or remove a file using 'mv' or 'rm', you =
would leave this database file out of date! The inode number strategy =
looks very elegant to me. Why isn't that handled this way in the =
current netatalk?

A caveat of the inode number approach would be the handling of =
deleted files and reused inodes. Suppose file f starts at inode i(f) =
and alias a points to f. Then, we delete f and create a new file g. =
If this file's first inode i(g) =3D=3D the former i(f), the alias a =
automatically would point to it. Isn't that so? Please correct me.

Cheers,
J=F6rg

------- End of Forwarded Message

---

From: Mario Klebsch DG1AM <[email-masked]>
Date: Thu, 26 Jun 1997 13:31:53 +0200

Hi!

>A caveat of the inode number approach would be the handling of >deleted files and reused inodes. Suppose file f starts at inode i(f) >and alias a points to f. Then, we delete f and create a new file g. >If this file's first inode i(g) == the former i(f), the alias a >automatically would point to it. Isn't that so? Please correct me.

Yes, thats the way it is (or would be). But a sollution could be to
use the ctime (cretion time) of the i-node to contruct "unreusable"
FileIDs. But it would be another 32 Bit of information, which probably
cannot be stored in FileIDs.

I just had a look at our local filesystem. The largest Filesystem
(2GByte) does have less than 2^20 inodes. This would leave 12 Bits to
make the FileIDs unique. My first idea is to use a hash function to
reduce the 32 bit ctime to 12 bit. Of course, this does not scale
well, so at least the number of ctime bits should automagicly adapt to
the exported filesystem.

But the inode aproach does have problems. Althoug UNIX internally does
all file accesses using inodes, the system call interface does not
provide any means to use inodes to access files. So accessing a file
by inode is expensive (if done in user space). NFS server typically
run inside the kernel, and so they can access the files using the
inode number. So this aproach probably would have to be implemented in
kernel, to be efficient.

Another problem is the fact, that the inode numbers are only uniqe on
the UNIX volumes. But netatalk does not export a UNIX volume, but a
UNIX directory tree, which can contain multiple volumes all having
their own uniqe inode numbers.

It all leads to the conclusion, that the 32 Bit FileID is a major
problem of scalability. NFS file handels are much longer than 32
bit. They are large enough to hold the information needed to locate
the files on the server.

73, Mario
-- 
Mario Klebsch, DG1AM, [email-masked]		+49 531 / 391 - 7457
Institut fuer Robotik und Prozessinformatik der TU Braunschweig
Hamburger Strasse 267, 38114 Braunschweig, Germany

---

From: "John R. Jackson" <[email-masked]>
Date: Thu, 26 Jun 1997 09:13:21 -0500

>.... But a sollution could be to
>use the ctime (cretion time) of the i-node ...

Not to start an argument, and a little off the subject, but there is
no such thing as "creation time" stored in a Unix i-node.  The "ctime"
field holds the time the i-node was last **changed**, e.g. with "chmod".
There is no way to determine when an i-node was created by looking at it.

The "ctime" field has confused and annoyed legions of programmers,
administrators and users for years.

More to the point of this discussion, ctime would not make a good
"uniquifier" because it can change during the liftime of an object just
like almost everything else in the i-node.

>73, Mario

JJ