On Sat, 14 Feb 2004 01:13 am, Derek Atkins wrote: > Thanks for offering to help with gnucash. I'd suggest that you > subscribe to gnucash-devel and we should move this discussion over > there. Please remove gnucash-user from the CC but leave gnucash-devel > in the CC when you reply.
Well, quicken under wine is frankly pissing me off :) My version doesn't allow me to create new accounts under windows (in cxoffice, either) so I have to boot to windows if I want to set-up a new accounts recievable or the like. I don't have a huge amount of time to spare, but if I can get agreement on what should happen I'm happy to put in a few hours a week until I get there :) Maybe starting next week, though. Today is valenties, after all. > > 3) Close and restart gnucash. > > Gnucash comes up ok, now, but is missing my unsaved transactions > FTR, what you did in #2 and #3 is exactly what "open anyway" does. Ahh, of course you're right. I had a vague recollection from last time I did it that it would create a different LCK file. I don't know why I thought that. > First, I don't see the LCK file management itself as a problem. It's > doing the right thing with the file; it's the UI surrounding the > existence of the lock file that's a problem. Besides, it's not just > NFS that has problems locking (and the lock problems are not > antiquated -- NFS _still_ has problems locking). The LCK file is also > used to detect crashes in the program to warn the user that there is > something potentially wrong. > This is key! When you start gnucash and it finds a lock file, there > is NO WAY to determine whether the LCK file exists because: > a) someone else is currently using the data file, or > b) gnucash crashed. 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? If OS locks are permitted, when gnucash opens the LCK file without creating it, and successfully gets a lock, it knows the last session crashed. Without OS locks a more elaborate scheme must be constructed to make the usual case work well for a crash: Open file: 1) Check for LCK file, and strongly suggest that the user not proceed if the LCK file exists. Preferrably even encode some indication into the LCK file as to who has the lock so that can be presented to the user for checking, or be checked automatically in local cases. 2) Start gnucash monitor process for the target file, use a pipe (or similar) between gnucash and gnucash monitor to ensure that gnucash monitor always sees a gnucash termination and vice versa (may not be portable to windows, do we care about that?) 3) Check for myfile.log, and offer to reapply the log's transactions any exist in the file 4) Create log file, and create/overwrite symlink (or simliar) as myfile.log Close file (after optional save): 1) Remove log file and symlink 2) Inform gnucash monitor of file close 3) gnucash monitor erases LCK Crash gnucash: 1) gnucash monitor erases LCK for open file(s) The important characteristics of this proposal are as follows: * The LCK file is created and deleted safely, without a need for OS locks, but it depends on having a small well-vetted gnucash monitor process. * If gnucash monitor dies or is prematurely killed the LCK file will still exist (gnucash should probably kill itself asap in this case) meaning that it is a failsafe arrangement. If the system fails it will assume the file is still locked, a safe assumption. The alternative assumption (to assume the file is no longer locked) would be unsafe. * 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 > > 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". > > * Lock the LCK file with a real OS lock so that you can ask the OS if the > > file is still locked. An OS lock will go away if your process crashes, > > but a file will not. > This is not sufficient and not portable. It also doesn't work on many > networked file systems. I find myself wondering about this, since tools like sqlite make heavy use of OS locking. There is really no better tool than OS locking and filesystems that don't support it should be shelved immediately. Hell, just use webdav! 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? Anyway. My alternative proposal is on the table :) > > So, is anyone looking at this? Would it be worth me looking at this? I'm > > a programmer, but haven't ever used gtk nor programmed in scheme. Have I > > missed something vital? Thoughts, anyone? > Why do you think you'd need to know scheme to do this work? You don't > need to know scheme for this; it's all C. Ok, I'll see if I can get my head into the gtk framework, then :) > You're welcome to add the code to do this, but honestly the XML file > storage backend has been deprecated, so I'd much rather see work done > towards real features. The plan is to move to an embedded SQL storage > like SQLite for the main storage, and relegate the XML format to where > it belongs: an interchange format for exporting and importing data. 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? Benjamin. _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
