On Sat, 22 Jan 2005, Dan McMahill wrote: > On Sat, Jan 22, 2005 at 02:18:05PM +0000, Martin Habets wrote: > > I agree locking is neededb but the proposal is not simple enough for me. > > Leave the details to the OS and just use fcntl(). Use F_SETLK to set the > > lock, and if if that fails use F_GETLK to get the pid of the process > > holding the lock. > > Given that failure would be a rare event it is enough to report the pid > > of the other process. > > does this work when you have multiple machines and networked file systems? > For example, the design is on system A, and you have designers on B and C. > B and C access the design files by NFS, AFS, SMBFS, etc. >
Well, a proper POSIX-compliant networked file system implementation *should* have POSIX file locking. However, you can appreciate that doing this reliably is much more complex and failure prone than on a single machine. In many cases it's the best solution, but it's still not a good idea to rely on this if you can avoid it. Unfortunately, lockfiles on shared file systems suffer from all of the same problems in addition to problems due to local cacheing. Stuart's proposal has merit, but it confuses two problems that really should be kept separate: programs sharing versus people sharing. For the program access problem, I strongly feel that POSIX file locks are the correct solution. This is what they are for. They have the great advantage that they automatically are removed when the file is closed. While we who are software developers can easily figure out when to remove a lockfile, it is often less obvious to others. For the people access problem, locking a file is pretty useless. The person making changes may be working on a copy, and may not even be in network communication (I do much of my design work on airplane flights!). This is what your revision control system is for. There is no need to reinvent the wheel here. I use CVS, and one of my gEDA projects was a collaborative design. CVS works very well with gEDA. So I think the correct paradigm is to assume that developers will primarily work on file copies in local file systems. Even if not, POSIX locks are more likely to work right for the program access problem than lock files are. For sharing between people some sort of revision control system is essential (and I wouldn't want to be without one even for solo projects), but as these are readily available and usable with gEDA no development is either required or desirable. John Doty "You can't confuse me, that's my job." MIT-related mail: [EMAIL PROTECTED] Other mail: [EMAIL PROTECTED]
