Subject: Netatalk and aliases

From: Aaron Levitt <[email-masked]>
Date: Thu, 15 Jun 2000 14:45:16 -0700

Greets everyone-

I am working in an environment that has just about every platform under the sun.  Mostly we have Macs.  We are in the process of doing away with some of our older Mac servers and replacing them with a linux server.  We have experienced a few problems, but most of them seem to have been worked out with the exception of one.  I have looked at just about every netatalk page/link I could find and have been unsuccessful as of yet.

If someone on a mac creates an alias on the netatalk share.  It doesn't seem to remember where it should point to.  If you unmount the share, and mount it again, the alias seems to point to other folders at random.  It mostly seems to be related to machines running OS9, but that could just be a coincidence.  Has anyone seen this before and/or know if there is a work around??  

Any help would be great appreciated.

Thanx in advance!
-Aaron

>>>>====--------====<<<<>>>>====--------====<<<<
Aaron Levitt		1616 Franklin Street
Systems Administrator	Oakland, CA  94612
Navis LLC		Tel:  510-763-5715
http://www.navis.com	Fax:  510-763-2516
>>>>====--------====<<<<>>>>====--------====<<<<

---

From: Norman Paterson <[email-masked]>
Date: Fri, 16 Jun 2000 09:25:09 +0100

>From man afpd:

"afpd's Directory IDs are only fixed for the duration of a session.  This
means that Mac aliases won't work correctly in all cases."

--
Norman Paterson, University of St Andrews
http://www.dcs.st-and.ac.uk/~norman/

---

From: "bryan stalcup" <[email-masked]>
Date: Fri, 16 Jun 2000 12:05:53 -0400

i get more complaints about this one issue than any other. i am not a
programmer (script some), so i know i don't understand the difficulty of
implementing this in netatalk, but a few thoughts come to mind.

assuming the DID's are a certain format, and that directories under unix
have a set inode (or id), couldn't an algorithm for creating a unique,
repeateable AppleShare IP DID from the unix inode resolve this issue? the
learning curve for me to implement anything like this seems so long, by the
time i could do it, someone else may have already long corrected it. still,
i have the desire to get in the code and contribute, it's frustrating to
point out problems without being able to help solve them. any suggestions on
where to start learning the C or C++ i would need to be able to help?

bryan

p.s. i'm having an issue with certain folders where files disappear and
reappear (a variation on the dancing icons, where the icons show up twice
and then the duplicate disappears). these files are files written to the
volume from an windows nt computer over samba, then moved to their final
directory on the mac side. i'm assuming it is some kind of resource fork
issue, but i'm not sure how to resolve it. any ideas?

---

From: Harry Zink/Netatalk List <[email-masked]>
Date: Fri, 16 Jun 2000 09:23:49 -0700

on 6/15/2000 2:45 PM, Aaron Levitt at [email-masked] wrote:

> Has anyone seen this before and/or know if there is a work around??

This is a known issue. You will find that the 'solution' offered by most
'experts' is to not use alias'.

This, while an interesting philosophical discussion, certainly does not
address the issue, nor solve the problem.

Unfortunately, I'm waiting for a resolution, just as you are.

Harry

---

From: Harry Zink/Netatalk List <[email-masked]>
Date: Fri, 16 Jun 2000 09:24:55 -0700

I asked this question before, but don't recall getting it answered:

Is there any difference in the netatalk shipping on Cobalt boxes, and the
one we are still toiling with?

Harry

---

From: "Jonathan Newman" <[email-masked]>
Date: Fri, 16 Jun 2000 14:13:45 -0700

> repeateable AppleShare IP DID from the unix inode resolve this issue? the

Adrian Sun sent this message to the list in February.  Note the comments
about DIDs and inodes. So there is an attempt at an alias fix in 38 and 39.
It doesn't work for everyone.

" Date: Mon, 14 Feb 2000 23:10:59 -0800
From: a sun <[email-masked]>
To: [email-masked]
Subject: test tarball available for omnis/fixed directory ids

hi all,

i just thought i should let everyone know that i've figured out why
omnis database doesn't like afpd. it turns out that omnis tries to
unlock non-existent locks. my locking code didn't handle that case. i
also went ahead and re-wrote the code a bit so that there's less
pointer twiddling, but i think it ends up being a wash in terms of
performance.

anyways, i've put a tarball for people to test at
<ftp://ftp.cobaltnet.com/pub/users/asun/testing/pre-asun2.1.4-38_test.tar.gz

it has the _test suffix because i currently have the codepage support
disabled. i'm in the midst of re-writing it to handle double-byte
codepages.

things i would like from testers:
       1) does it compile under redhat 6.1 without complaints about
          sendfile and libwrap?

       2) does it preserve aliases correctly? i'm currently using a
          24-bit hashed file/directory id field + 1 bit file/directory
          identifier + 7 (4 major/3 minor also hashed) bits for the
          device.

       3) as a side-effect of what i did for #2, does sherlock run
          more quickly?

       4) does locking appear to work correctly? use your favorite
          database program to test this.

-a
[email-masked]"

Jon Newman
[email-masked]