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

[Chris Shoemaker <c.shoemaker@cox.net>]

On Fri, Feb 10, 2006 at 09:13:44AM -0600, Christopher Friesen wrote:
> Joerg Schilling wrote:
> >"Christopher Friesen" <cfriesen@nortel.com> wrote:
> 
> >>There's nothing there that says the mapping cannot change with 
> >>time...just that it has to be unique.
> >
> >
> >If it changes over the runtime of a program, it is not unique from the
> >view of that program.
> 
> That depends on what "uniquely identified" actually means.

"The st_ino and st_dev fields taken together uniquely identify the
file within the system."

> One possible definition is that at any time, a particular path maps to a 
> single unique st_ino/st_dev tuple.

The quoted sentence certainly implies _at_least_ that much.

> 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.

> This second possibility seems easily disproved.  If you delete and 
> recreate files on a filesystem (assuming nobody has open files in the 
> filesystem), at some point a new file will end up with the same inode as 
> an old (deleted) file.  The two files are different, but have the same 
> st_ino/st_dev tuple.
> 
> This leaves the first possibility as the only choice...

If you want to show that his interpretation is incorrent (which it
may be for all I know), you need a better argument than this.

-chris

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