Re: documentation vs specification

On Mon, Oct 3, 2011 at 2:50 PM,  <[email protected]> wrote:
> On Mon, Oct 03, 2011 at 01:46:31PM -0500, Nico Williams wrote:
>> However, I insist that it's perfectly feasible to expect a POSIX
>> semantics filesystem on any Unix where one would use a file ccache
>
> I do not mind. What is needed is "how to use the (Posix) file system
> for the purpose".
>
> creat()+write()+rename() yields "stale data unless the
> cache is reopened" for a reader but does not need any locking;

Apps generally re-open the ccache.

> lock()+truncate()/seek()+write()+unlock() is more complicated and can
> lead to an inconsistent reader state. Locking is also a can of worms
> itself (what if the writer stalls?).

Indeed.  I recommend against this.

> So I would suggest going creat()+write()+rename(). A reader should
> periodically re-open() to refresh its view if necessary. A random new
> name makes it safe against name-based attacks.

Not periodically: whenever they need to use the ccache (and only if
the stat of the path has changed st_fsdev and st_ino, but whatever,
this is all in tmpfs, so it's fast, so who cares).

> The crucial thing (not that big actually?) is to document the/some
> choice so that the implementors of any team, including future ones,
> would have a reference and would be able to write compatible code.

So far the source code has been the documentation.

Given that the ccache and keytab file formats are shared by multiple
implementations, I agree, they ought to get documented.  We could use
volunteers :)

>> (does Rune have *any* examples of a Unix with no tmpfs and no UFS
>> /var/tmp??), and that otherwise one ought to use CCAPI.  One would
>
> No, that was Harald's "side track" example. I am fine with relying
> on the presence of some Posix-like writable file system.

Ah, sorry.  Good.

Nico
--