Subject: [netatalk-admins] DIDs - an idea -or- I didn't read the AFP specs completely yet

From: Andras Kadinger <[email-masked]>
Date: Wed, 15 Apr 1998 03:03:54 +0200 (MET DST)

Dear List Readers,

I was thinking about the DID issue, and hunted down Inside Appletalk,
where in the AFP section I found a sentence stating, that a DID should
never be assigned to a different directory during the lifetime of the
volume. This made me think about a somewhat dirty hack, which seems to
work in theory until now - please, disprove me in either direction. :-) 

For we can not use a DID number we already used, we should maintain a
'high water mark' for the volume, like .maxDID or .AppleDouble/.maxDID. 
When we create a directory (or find one without a DID, like one created in
unix), we assign maxDID to its DID, store it as - let's say -
.AppleDouble/.DID, and then bump .maxDID.

Looking up the directory's DID is as simple as getting the value from
.AppleDouble/.DID - no database lookups or other complex issues, making
this approach ideally suited for use in a Quick Hack (tm) environment. If
someone moves or renames the directory, the DID holds, and fulfills its
purpose. If someone removes the directory then the DID is also lost, but
with around 2^32 possible DIDs for a volume most of us can live for a
while (remember, this is supposed to be only a quick hack :-) ) - not to
mention Inside Appletalk's explicit behaviour requirement. I think,
locking the volume's .maxDID as a complete file (since it doesn't hold any
other information) would not be an issue for most unices netatalk runs
under - I hope I don't step on a toe here.

This seems to be too simple for me to believe it's right.

Where am I wrong?

Wesley, would this fulfill Your requirement for the DIDs to be stored in
the filesystem? Would this work across NFS?

Sincerely,
Andras Kadinger
[email-masked]

---

From: Andras Kadinger <[email-masked]>
Date: Wed, 15 Apr 1998 04:06:47 +0200 (MET DST)

Wesley,

On Tue, 14 Apr 1998 [email-masked] wrote:

> > From:    Andras Kadinger <[email-masked]>
> > To:      [email-masked]
> 
> The only thing you're missing is the need for a DID -> pathname
> database.  This is required for resolving aliases, in particular.
> Lacking such a database means searching the filesystem for an
> appropriate DID.

Hmm. Then the .maxDID thing could be expanded to .DIDdb, which would only
be modified when handing out a new DID, or when looking up a pathname from
a DID results in a nonexistant pathname (we might want to fall back to
searching the filesystem in this case, if we care about keeping Mac
aliases for directories moved from unix) - so the whole file locking still
might be feasible. Yes, I knew this was _rather_ lacking somewhere.

> Also, there's the case where someone mounts /home, and you've already
> got /home/bandit mounted. 

You mean AFP-mounting 'nested' volumes - subtrees?

1) We might want to say 'don't do that', just like other AFP servers do -
I can not realistically imagine a scenario where such 'nested' mounting
might really need working aliases, but that's only me.

2) We might want to search upwards for a .maxDID or .DIDdb thing, and use
that. If the .DIDdb database stores only relative pathnames from the
AFP-volume's root, using the 'parent's' one for the nested volume
(prepeding the path difference) might be doable, though this is ugly at
first sight.

3) We might want to do automatic .DIDdb updating/building when necessary
(e.g. there is a parent/child dir with a more recent .maxDID).

Did I say Quick Hack(tm)?

Sincerely,
Andras Kadinger
[email-masked]

---

From: [email-masked]
Date: Tue, 14 Apr 1998 21:40:45 -0400

The only thing you're missing is the need for a DID -> pathname
database.  This is required for resolving aliases, in particular.
Lacking such a database means searching the filesystem for an
appropriate DID.  Also, there's the case where someone mounts /home,
and you've already got /home/bandit mounted.

:wes

---

From: Michael M Han <[email-masked]>
Date: Wed, 15 Apr 1998 09:42:34 -0700

A netatalk user has forwarded me his source tree in which he
implements persistent DIDs. The approach he took was to derive DIDs
from inode numbers, knowing full well that any volume spanning
multiple filesystems will cause trouble and naturally avoiding such a
thing.

I'm currently in the process of un-fixing the things he's fixed in his
source (various patches to fix this and that) to produce a patch that
will apply cleanly to a distribution. If anyone, like me, is truly
desperate for persistent DIDs, please let me know. I'd be happy to
forward you a patch, once I have one that works.

Thanks, Roland, for bailing me out.
_________
mike ([email-masked])
I will not Xerox my butt
 - The collected wisdom of Bart Simpson

---

From: Incze Lajos <[email-masked]>
Date: Wed, 15 Apr 1998 22:00:18 +0200 (MET DST)

> .AppleDouble/.DID, and then bump .maxDID.

My idea was to use the unsigned long returned by time(). Then the
TIME will maintain your uniqness. And no need for the .maxDID bump
which has a race condition.

> This seems to be too simple for me to believe it's right.

Seems to work.						Incze

---

From: Andrew McNabb <[email-masked]>
Date: Wed, 15 Apr 1998 16:44:50 -0500 (CDT)

What happens if you change your system clock (esp. dailylight savings)?
Also, what if you have two files created during the same second (not
unlikely if you have a big system).

> > This seems to be too simple for me to believe it's right.

----------------------------------------------
                Andrew McNabb
             Argus Systems Group
          [email-masked]
----------------------------------------------
  I am an International Arms Trafficker!!!!!
http://online.offshore.com.ai/arms-trafficker/
----------------------------------------------

---

From: Andrew McNabb <[email-masked]>
Date: Wed, 15 Apr 1998 16:45:46 -0500 (CDT)

Can you work with Adrian and see if you can have it put into his patchset
soon (assuming it works well)?  I would really appreciate it.

---

From: "Gary E. Bickford" <[email-masked]>
Date: Wed, 15 Apr 1998 16:45:44 -0500

Time has only one-second granularity.  This is OK for many things, but
(IMHO) not quite enough for very active servers.  There  are some "unique"
functions around based on a combination of time and system clock that would
work, however.

There is a function called uniqid () in the PHP source library (available
under the GNU license at http://php.iquest.net, or http://www.php.net for
the new version 3), which uses gettimeofday.  This code is not directly
usable, as it is specific to the PHP data structures. but may be useful to
someone on the list.

   gettimeofday((struct timeval *)&tv, (struct timezone *)NULL);
    sec = (int)tv.tv_sec;
    usec = (int)(tv.tv_usec % 1000000);

    /* The max value usec can have is 0xF423F, so we use only five hex
     * digits for usecs:
     */
    sprintf(uniqid, "%s%08x%05x", prefix, sec, usec);
    Push(uniqid, STRING);

GEB