Re: key64_t? ino64_t?

[Robert Collins <rbcollins at cygwin dot com>]

On Thu, 2003-05-15 at 14:22, Charles Wilson wrote:

> When I saw : 'key = NextKey++' in your implementation, I just *knew* that
> NextKey couldn't be an integer type.  Because that would be awful.  No,
> NextKey was a FTOKNode, with a specially overridden assignment-to-integer
> operator and operator++.  Because simply assigning keys based on the
> order of insertion couldn't POSSIBLY be what your were proposing, because
> it violates the determinism principle (see below).

Huh? It doesn't violate determinism within the ftok requirements, AFAIK.
Once you start cygserver, the same key will always be returned for the
same path, and never for a different path. The same cannot be said for
your algorithm. (BTW: chasing of symlinks is implied by the 1003.1
description of error codes.

> But it means that the returned key number IS dependent on something OTHER
> than the fully expanded pathname.  It's also dependent on the execution
> order of all other IPC processes on the system.
>
> Surely that's not good.  You once said that 
> "hashs collide. key_t's can not collide under any circumstance, and must
> be deterministic (i.e. not dependent on currently issued keys)."

My turn to defend statements :}. I should have been more precise:
"ability to be used my not depend on currently issued keys". I was
referring to the case of an accidental duplicate being issued do to the
hash value being part of the key.

> But simply counting all previously issued keys is deterministic only in
> the (1) sense, not in the memory-less (2) sense.
> 
> Soooo.... ???

I was unclear and caused confusion.

Look, I think we are going down a rabbit hole.

In fact, I think we've left poor Alice far far behind.

Basic alternatives:
1)  A lossly-reduction-in-bitsize-from-NT-native-data approach.
2)  A bigger-than-64-bit-key-with-all-NT-native-data approach.
3)  A remember-issued-keys approach.

1) will from time to time do the wrong thing.
2) will never do the wrong thing, or at most will do it wrong on hard
links link linux does.
3) will never do the wrong thing, but at a cost.

I've wavered towards and away from 3). I really don't like 1) - I see it
as unchanged from the current compromise. And you don't like 2) because
of some concerns (not demonstrated in code) about ease of use in client
programs.

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part