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.
Better to argue that SUS is wrong than to pretend it didn't say what it
did.
> > SUS quite clearly states that fsync should
> > not return until you are sure of having recorded not only the
> > file's data, but the access path to it. I interpret this as being
> > able to "access the file by its name", and being able to guess by
> > looking in lost+found doesn't count.
>
> But that is just an interpretation. There's nothing in the spec
> which forces that interpretation.
Well, look at the name "lost+found". It's lost, maybe we found the
data but the name is gone for good. 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.
> fsync forces the data to disk. There may be one or more pathnames
> which the application also relies on, and if the application does
> care about those, the application will have to ensure that they are
> synced too.
>
> 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"?
-- Daniel - 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/