Re: [Gnu-arch-users] Re: Questions from a Subversion user

[Tom Lord]

    > From: Andrew Suffield <address@hidden>

    > > The locking mechnanisms in arch do not have race conditions and are
    > > robust for multi-user concurrent access.   They rely only on some
    > > least-common-denominator properties of `mkdir' and `rename' -- safe,
    > > even, on NFS.

    > No Files are Safe.

    > It's always possible that your mkdir()/rename() lands on the wrong
    > thing entirely, because NFS has gotten its inode numbers in a twist
    > again :P

Yeesh.   Sounds like a bogus implementation -- something that manages
file handles poorly, perhaps?   I don't _recall_ that such problems
are intrinsic in the protocol and seem to recall working on an
implementation that didn't suffer from such bugs.....

It is a pretty skin-of-our-teeth kind of protocol, though.


When I say "safe for NFS", what I specifically mean is two things
which are not true on other file systems:

1) I do not rely on mkdir(2) having the property that only one client
   get's a 0 return (indicating no errors) for a given directory.
   In other words, roughly concurrently, client A and client B can 
   both create directory X and both clients think they succeeded.

2) I do not rely on rename(2) having the property that only one client
   can succeed at that.   In other words, roughly concurrently, 
   client A and client B can both rename X to Y and both clients think
   they succeeded.

Those limitations of NFS stem from its being designed as a stateless
protocol, able to be implemented over unreliable transports.


-t