Re: CD writing in future Linux (stirring up a hornets' nest)

[Chris Shoemaker]

On Fri, Feb 10, 2006 at 09:53:37AM -0600, Christopher Friesen wrote:
> Chris Shoemaker wrote:
> >On Fri, Feb 10, 2006 at 09:13:44AM -0600, Christopher Friesen wrote:
> 
> >>That depends on what "uniquely identified" actually means.
> >
> >
> >"The st_ino and st_dev fields taken together uniquely identify the
> >file within the system."
> 
> >>The other possibility (and this is what you seem to be advocating) is 
> >>that a st_ino/st_dev tuple always maps to the same file over the entire 
> >>runtime of the system.
> 
> >However, I don't think this is a reasonable interpretation, and it's
> >clearly _not_ the one that Joerg is implying.
> >
> >Joerg is claiming that the quoted sentence also implies that
> >_different_ st_ino/st_dev pairs will _always_ identify different
> >files.  Taken in just the immediate context of stat.h, this is a
> >very reasonable interpretation.
> 
> It seems to me that "st_ino/st_dev tuple always maps to the same file" 
> is equivalent to "different st_ino/st_dev pairs will always identify 
> different files".  What is the distinction between the two statements?

This distinction is probably quite important.  

The first assertion is that this is an injective mapping from the
domain of files to the range of st_Ito/st_dev pairs.

The second assertion is that this is an injective mapping from the
domain of st_Ito/st_dev pairs to the range of files.

The first may be true even when the second is false.

I'm no expert on SUS, but if a spec says "X uniquely identifies Y"
it's almost certainly asserting that there's an injective mapping from
the domain of X into the domain of Y, and it's probably also
reasonable to infer that the mapping in the other direction is also
injective.

> As I see it, the main question is whether it is a unique mapping *at one 
> specific point in time*, or is it a unique mapping *for the duration of 
> the system*?  Note that in this case "system" includes "parts of the 
> tree that may be remotely mounted from other machines on the network".
> 
> I would suggest that the spec doesn't specify the duration of the unique 
> mapping, and thus as long as there is a unique mapping *at any 
> particular point in time*, then there is no conflict.

In the absense of a specified duration for which the property must
hold, it's unfortunately necessary (albeit, somewhat dangerous) to
*infer* the duration based on the intended *use* of the property
(e.g. equality testing).  Two parties which intend to employ the
property for different purposes may infer two different durations - a
typical spec deficiency.

> If we read it as requiring a unique mapping for the duration of the 
> system, consider a hypothetical "system" that includes all the devices 
> of all the computers on the planet, and they are all dynamically 
> appearing and disappearing continuously.  Consider the technical 
> challenge in ensuring that each file on this hypothetical system is 
> permanently and uniquely identified by a device/nod pair.

It seems this example only presents a challenge to ensuring the
*inferred* requirement of the injective mapping from files to pairs,
not for ensuring *only* the explicit requirement that pairs uniquely
identify a file (but not necessarily that they uniquely identify *one*
file).

-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/