In article <20030216034123.0B2DD62AA@mail.asahi-net.or.jp>,
	ttaka@earth.email.ne.jp (Toru TAKAMIZU) writes:
>> - Add --with-did=last, to avoid having to create a dependendency on db3.
>>    --with-did=last was the default with netatalk 1.5.5.
> 
> But according to doc/INSTALL,
> 
>   The last DID scheme recreates version 37b behaviour where
>   directory id's are incrementally calculated versus the new
>   hash method. Unfortunately for machines that have a lot of
>   devices, and/or a lot of inodes the hash can fail with
>   multiple directories resolving to the same DID.
> 
> So, some (or many?) of us feel uneasy about this.
> What do you think about it?
> 
> Please Cc: me, because I'm not subscribed.

Interesting. How much is "a lot", and what's the failure mode when the
calculation rolls over? I mainly went with that, because

1) It didn't build without it, though the fix may be as simple as adding
--with-db3-includes=...

2) The warning in the 1.6 release notes that cnid "needs testing".

3) It shouldn't be any worse than it was before (1.5.5). At least one
user claims that *1.4.2* works better,

   http://mail-index.netbsd.org/port-mac68k/2003/02/15/0001.html

so I thought it prudent to be conservative.

4) Especially, this

* FIX: CNID, folders' DID handling with concurrent access or symlinks.
        (Fixes an endless loop in afpd.)

from the draft release notes for 1.6.1,

  http://sourceforge.net/mailarchive/forum.php?thread_id=1628404&forum_id=4958

lead me to believe that cnid wasn't quite ready for 1.6.

I'd be OK with enabling it, though, for the 1.6.1 package (1.6.1 is
promised to be out in a couple of weeks), especially if you'd like to
submit patches to make it build.

-- 
Frederick