Subject: moving aliases

From: Richard Chamberlain <[email-masked]>
Date: Mon, 12 Nov 2001 16:42:52 +0000

Hi,

We've got a problem with moving aliases using the netatalk rpm package that 
comes with SuSE 7.2 (the version according to the rpm is 1.49).

Basically when a user creates an alias of a folder or file on the server 
when he restarts his mac it will point elsewhere. Mac OS versions vary from 
8.6  up to 9.2.

I've put a message on the netatalk sourceforge help forum but to no avail 
as yet.

Anyone seen anything like this before?

I thought I'd try upgrading to the latest version of netatalk, but my 
skills don't go much beyond ./configure,make,make install and that didn't work.

Any pointers would be greatly appreciated,

Many thanks,

Richard

---

From: Bob Hobbs <[email-masked]>
Date: Mon, 12 Nov 2001 17:08:52 +0000

> when he restarts his mac it will point elsewhere. Mac OS versions vary from

Mac aliases point to files or directories by a reference number, rather than
by name; for files on UN*X volumes netatalk has to make up those reference
numbers out of thin air, and as I understand it, it doesn't remember what
values it used from one session to another.

I've never even tried it but the impression I get is that you can't make
aliases to anything on a netatalk share... There's some info about this
scattered around the netatalk documentation (in the doc directory in the
source distribution, and in the man pages).  I seem to remember there's a
build option related to this issue, which might help you (sorry to not be
more specific).

--Bob

---

From: Thomas Schierle <[email-masked]>
Date: Mon, 12 Nov 2001 21:19:06 +0100

The 1.49 rpm that comes with SuSE 7.2 is compiled using the lastdid option.
Means Macintosh directory/file ID numbers (DIDs) for folders/files are
computed just in RAM by the Netatalk server for every single client process
and therefore are valid for just a single session.

The developer team is busy working onto the problem (tying DID numbers to
Linux node IDs or a separate database), but there is no foolproof solution
available yet. If you are an experienced admin, you might want to check out
a recent copy from CVS at sourceforge and play around.

-Thomas

-- 
Thomas Schierle, Munich, Germany

PGP key [DSS/DH] 0xA23CDA1D available at various public key servers