No subject

       O_EXCL When used with O_CREAT, if the file already exists  it  is
an
              error and the open will fail. In this context, a symbolic
link
              exists, regardless of where its points to.  O_EXCL  is
broken
              on  NFS file systems, programs which rely on it for
performing
              locking tasks will contain a race condition.  The solution
for
              performing atomic file locking using a lockfile is to create
a
              unique file on the same fs (e.g., incorporating  hostname
and
              pid),  use  link(2)  to make a link to the lockfile. If
link()
              returns 0, the lock is successful.  Otherwise, use stat(2)
on
              the unique file to check if its link count has increased to
2,
              in which case the lock is also successful.

(apologies for the crap formatting).
I believe this is a very cross-platform widely used solution to the
brokenness of NFS.
If this isn't a solution - why are you depending on valid timestamps on
the lock files? The source files, I could understand.
If you need reliable mtime/ctime updates, I believe Linux's 'noac' NFS
mount option might be what you want. I don't know about other platforms.

As the previous poster said, a network daemon might be a better idea. Even
have the daemon do the source file I/O, and get rid of NFS entirely.
<shrug>

--m@

On Mon, 15 Jul 2002, Jack Lloyd wrote:

> 
> Problem:
> 
> We need to do some kind of locking such that one server runs over a
> particular set of files (in this case, a source code repository). More than
> one server can run, just not over the same repository.
> 
> Current Solution:
> 
> Do a lock file. It works, but only on a local filesystem (since we depend
> on good timestamps and whatnot).
> 
> New Problem:
> 
> Need to make sure that the repository is on a local filesystem.
> 
> Current Solution:
> 
> Use statfs and check for NFS_SUPER_MAGIC. The problem is that NFS is not
> the only remote file system in existence, last I checked. Is there a better
> solution to this beyond just checking for CODA_SUPER_MAGIC,
> SMB_SUPER_MAGIC, etc along with NFS_SUPER_MAGIC?
> 
> Offtopic to this list:
> On *BSD, we do a statfs and check the flags for MNT_LOCAL. And everywhere
> else, we punt and say "yes, it's local". Anyone know of a way to check for
> this on Solaris, IRIX, etc? I can't find anything at all for this.
> 
> 
> _______________________________________________
> This is the Linux C Programming List
> :  http://lists.linux.org.au/listinfo/linuxcprogramming List
>