On Mon, Jun 23, 2003 at 09:43:50AM -0400, Anocha Yimsiriwattana wrote:
> > > >     http://www.gnucash.org/docs/C/gnucash-guide/backup1.html
> >
> > If I interpret the documentation right, the locking GnuCash uses is
> > file creation in exclusive mode.
> >
> > Though such operaton is not guaranteed to be exclusive on Coda,
> > normally it will not fail, so GnuCash should be happy (and clean the
> > "lock files" afterwards).
> > Looking at the source or strace results would possibly give the answer,
> > why you seem to observe that problem on Coda but not otherwise.
> 
> I did not means to be too offensive, but I did check in the GnuCash and does 
> not assume it is only CODA problem.  I have download GnuCash and
> take a look at the code.  The section of GnuCash code that does locking is 
> attached at the end.  I agree with Ivan that GnuCash uses exclusive mode.

I looked over the source, and now I'm intrigued, although Coda should
give the right 'locking' properties that GNUCash might expect, the .LCK
file should not end up lying around. So I'm assuming some kind of bug is
there, maybe we're incorrectly blocking the unlink of a file that has no
unix permissions and 'rm -f' internally does a chmod if the unlink fails
the first time and thereby hides the problem in normal usage?

> Is it possible to implement locking mechanism in CODA?  I am a newbie to CODA 
> code "hacking" :-P ... 

Not worth it. What would a server do with a locked file if the locker
goes disconnected. If we automatically unlock it basically throws away
all lock guarantees because we could have a temporary disconnection due
to a network or router problem. But if we leave the locks around we're
screwed when the user went disconnected to go away on vacation or
reinitializes his Coda client and will need to allow administrators to
unlock such locks, and we're back at not being able to guarantee the
exclusivity of the lock.

And the one that does it for me, how could I possibly lock a file when
I am disconnected, and if we 'provisionally lock it' what would happen
when we return and find the file locked, or even unlocked but modified.

Arguably, as soon as we have an application that requires extensive
locking, it is probably not well suited for Coda. Such an application
seems to expect (frequent) concurrent updates whereas the optimistic
strategies in Coda were designed with infrequent writes and negligible
write sharing in mind.

If we were to assume frequent and/or concurrent writes, I would assume
the final design to be wildly different from what Coda is doing. Trying
to retrofit some locking scheme with vague semantics into the existing
design is in my eyes more than just a bad idea, similar to the
implementation of the chunked file transfers in AFS.

I couldn't quickly find a better description of the problem, but this
email contains an example where AFS completely loses AFS semantics,

    http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2001/3833.html

Jan