Subject: Re: Mac Aliases changing

From: [email-masked] (Dean Batten)
Date: Mon, 23 Jun 1997 19:32:49 -0400

The user is most likely correct. There was a lengthy discussion a month or
so ago on the linux-atalk mailing list about this.

If I recall correctly, there are three ways you can refer to a file--path,
folder id + filename, and file id. While the path reference is consistent
between mounts of a Netatalk volume, the folder and file id's are not. A
Finder alias, unfortunately, uses one of the reference methods for which
Netatalk is inconsistent: each mount of the volume, the alias will point to
something different.

>Folks,
>
>Netatalk 1.4b2 on Solaris 2.5.1, no afs.
>
>I have more than one Mac user who claims to have made an alias to a
>folder on the Sun box that, overnight, 'changed' and now points to a
>different directory on the Sun box.  Anyone else seen this?  They've
>done it several times, so I don't think they are the ones messing up.
>
>Peace,
>--
>  Matt McLean                                      Systems Administrator
>  School of Information & Library Studies                  Tifosi

Dean Batten ........ Batten Consulting ... 610/437-3516
[email-masked] . Allentown, PA ..... www.batcon.com

---

From: Mario Klebsch DG1AM <[email-masked]>
Date: Tue, 24 Jun 1997 01:35:32 +0200

Hi!

>Netatalk is inconsistent: each mount of the volume, the alias will point to

But afp does announce, wether the server supports FileIDs or not. And
I would use I-Node numbers as FileIDs. They are constant as long as
the File exists. However unlike real FileIDs, I-Node numbers get
reused.

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: Bill Studenmund <[email-masked]>
Date: Tue, 24 Jun 1997 13:03:11 -0700 (PDT)

> the File exists. However unlike real FileIDs, I-Node numbers get

If I remember that thread correctly, the problem is that the folder ID's
are inconsistant, and so even w/o FileID support, there's a problem.

I think (I've not browsed that source recently) that the problem's that
the folder ID's are generated as the directories are walked.

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.

Take care,

Bill

---

From: [email-masked]
Date: Tue, 24 Jun 1997 22:10:48 -0400

> From:    Bill Studenmund <[email-masked]>
> To:      Mario Klebsch DG1AM <[email-masked]>

> 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
tree.  As a matter of fact, you could get around some of its other
short-comings this way as well, e.g. no support for file names > 31
characters.

:wes

---

From: Stefan Bethke <[email-masked]>
Date: Wed, 25 Jun 1997 12:45:56 +0200

>short-comings this way as well, e.g. no support for file names > 31

How would you keep that in sync with the real tree?

The basic problem is that you have to keep file system meta-information
(File ID, Parent ID), which does not fit into the standard Unix file
system, somewhere, and keep this information in sync with the
meta-information in the file system. The Right Thing To Do would be a VFS
module to keep the info where it belongs.

Using a hidden file to store the directory ID still has two problems: it is
possible that two dirs get the same ID, and locating a dir by its ID.
Unless you keep a file at the root of the tree, storing the IDs of all
dirs, finding the dir could be quite expensive.

Stefan

--
Stefan Bethke
Promo Datentechnik      |  Tel. +49-40-851744-0
+ Systemberatung GmbH   |  Fax. +49-40-851744-44
Eduardstrasse 46-48     |  e-mail: [email-masked]
D-20257 Hamburg         |  http://www.Promo.DE/

---

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

Hi!

>short-comings this way as well, e.g. no support for file names > 31

IMHO this would lead to some of new problems. The main problem is the
single file in the root directory. An aproach with a file in each
directory would be better.

The main reason is, that you do not have to mount the same directory,
each time. You even can mount a directory and its parent as two
different volumes on the same or on different machines. So each of
these mounts would have its own file in its own root directory, but
partly containing information about the same files. It is almost
impossible to keep thes files up to date.

Keeping them up to date also is a problem, when the same directory is
accessable by other means then afp, too. If it is mounted on a PC
using smb or directly used by UNIX processes, the files contets will
always be outdated.

73, Mario

---

From: [email-masked]
Date: Thu, 26 Jun 1997 08:53:11 -0400

> From:    Stefan Bethke <[email-masked]>
> To:      [email-masked], Bill Studenmund <[email-masked]>

> How would you keep that in sync with the real tree?

You'd have a simple database that several afpd's could modify at once.
The first few routines in etc/afpd/directory.c would need to be
modified.  The format could be very similar to a Unix directory, with
free extents, etc.  If a Unix file got deleted with "rm", then the
database would be modified by the first afpd to notice the
discrepency.

:wes

---

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

>database would be modified by the first afpd to notice the

Sounds much better that the aproach with the singel file in the root
directory. To check for file removal (and creation or renaming) you
could store (and check) the directories mtime in the database. Reading
the directory is only necessary, when it has changed.

73, Mario

---

From: Thomas Lamy <[email-masked]>
Date: Thu, 26 Jun 1997 14:23:54 +0000

>the directory is only necessary, when it has changed.
I've followed the discussion for some time, and I think Helios (Ethershare) has done "the right thing" in this case:

First, they have a single database for each volume, .Desktop, holding APPL-Signatures, Icons, and the file- and directory id database. This db is managed by a single process, called desksrv. The afp server processes communicate with the desksrv via RPCs.
Second, they have the id of each file/directory stored in a file named ".rsrc/<file/directory name>". This is to reduce RPC overhead, as afp servers open this file anyway to get the finder information, and to rebuild the desktop database if it became corrupted.

I'm working on this approach inside netatalk for 3 moths now (in my spare time, which is not that much :-()

Thomas

Thomas Lamy                    Vision Connect GmbH    Telefon: (089) 356256-35
Database Development Division  Taunusstraße 51        Telefax: (089) 356256-56
mailto:[email-masked]    80807 München          http://www.v-connect.com/