> I'm saying that, when the intent is clear as it is in this case then
> trying to find loopholes in the form of expression is not useful.
The intent is perfectly clear regarding the data. It is totally
undefined regarding names.
> Well, look at the name "lost+found". It's lost, maybe we found the
> data but the name is gone for good.
That's fine --- it satisfies the SUS requirements.
> On the other hand, if we start
> with the same on-disk state that fsck had before creating the
> lost+found, but use a journal to recover the name, it *does* count
> because we have a deterministic mechanism for making fsync's promise
> come true.
That's an implementation decision, not a comment on the spec.
> > Look, I agree that your interpretation is useful. It's just not an
> > unambiguous requirement of the spec.
>
> OK, fine, this damn English language and all that. Do we agree that
> "access" means "be able to open by name"?
The word "access" isn't used there in the spec, so it doesn't matter.
The spec only refers to "all file system information required to
retrieve the data." Integrity of the data is the only thing
guaranteed, not integrity of the namespace.
Cheers,
Stephen
-
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/