Benjamin <[EMAIL PROTECTED]> writes:
> Hmm.. so just to be clear, the reason you don't use OS locks is definitely
> 100% that correct locking semantics may not be available? I want you to be
> absolutely clear on that point, because sqlite is based on the assumption
> that such locks will be available. Does this mean you'll retain the LCK
> method with sqlite and not permit multi-user access for that file format?
Hmm.. honestly I'm not 100% sure that this is the reason it's done
the way it currently is. There is this comment in the code:
/* OK, now work around some NFS atomic lock race condition
* mumbo-jumbo. We do this by linking a unique file, and
* then examing the link count. At least that's what the
* NFS programmers guide suggests.
* Note: the "unique filename" must be unique for the
* triplet filename-host-process, otherwise accidental
* aliases can occur.
*/
/* apparently, even this code may not work for some NFS
* implementations. In the long run, I am told that
* ftp.debian.org
* /pub/debian/dists/unstable/main/source/libs/liblockfile_0.1-6.tar.gz
* provides a better long-term solution.
*/
Unfortunately we don't have the file history prior to 7 Aug 2001 when
Dave Peticolas moved the files around, so I don't know who wrote these
comments or why. Personally I have no objection to using flock() or
fcntl() to lock the .LCK file.
[other stuff elided]
A monitor doesn't work for the same reason you can't trust gnucash to
close down... The monitor may crash, or the computer may crash, or
there may be some other reason that the .LCK file sticks around... So
I need to cope with it regardless.
> * The user doesn't have to "find" the log file in the normal case because of
> the symlink (or equivalent), but can still reapply old ones from the import
> menu if needed using the existing dialogue
You can already do this.. You know the name of the data file, so you
know the log file is going to be the most recent .log file with the
right naming format in the same directory as the data file and with
the same naming scheme as the data file. All this is easily computed
or determined at runtime.
>> > Anyway, here is my proposal:
>> > * Write the name of the log file into the LCK file, or use the LCK as
>> > your log file
>> I see no reason to do this. Why do you feel this would help?
>
> This is to avoid the user having to be given a file find dialogue to locate
> the log. gnucash can simply say "apply the log the last gnucash process that
> opened this file had open".
As I said, you can easily compute this at runtime.. But I have no
objection to this approach, I just find it unnecessary.
> Should we really complicate things so much for a simply broken architecture?
> Do real gnucash users have this kind of system and want to keep it?
I don't know. I certainly use file systems that don't support byte-range
locking.
> Anyway. My alternative proposal is on the table :)
Yea, I think I'd rather use OS locks if we can make sure it works with
NFS and Samba.
> If you care about the lock-less network filesystems, it sounds like you need
> at least some of this functionality even with sqlite. How far off is the
> sqlite file format from becoming a reality?
Unfortunately it's still pretty far off; I've been waiting for Matthew
Vanecek's SQL changes. So, at this point it's still a pipe-dream.
It's high on my priority list, but it's not at the top of my list.
> Benjamin.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
