Could you try to reproduce this with GnuCash 2.4.0 ? There were problems with the logfile cleanup code that might result in similar problems.

With GnuCash 2.4.0 on a Debian system an attempt to 'save as' in a sqlite3 format results in the following error message:
The server at URL sqlite3:///mnt/Mounts/Carol2_C/Data/GNUcash data/TestDB.gnucash experienced an error or encountered bad or corrupt data.

A 0 byte data file is created in the destination directory on the Win XP server.

An attempt to 'save as' in an xml format without restarting GnuCash results in an attempt with no results and return of control to the user.

After a GnuCash restart, an attempt to 'save as' in an xml format results in this message:
GnuCash could not obtain the lock for xml:///mnt/Mounts/Carol2_C/Data/GNUcash data/TestDB.gnucash. That database may be in use by another user, in which case you should not save the database. Do you want to proceed with saving the database?

If 'Yes' (actually the choices are cancel or save) is selected then the file is written correctly with 2 log files also.

If you need more data please do not hesitate to request it.

Ok, what version of libdbi do you have installed on your system ?

libdbi is ver 0.8.2-3.  libdbd-sqlite3 is ver 0.8.2-1-4.1.

That version should be ok.

I'm trying to understand what you are reporting here, so let's try to clarify your situation.

1. you are trying to save to a network mounted share on a Windows XP machine. How was it mounted ? Did you use the cifs protocol or the smbfs protocol ?

2. It's not really clear to me if you always get "the couldn't obtain lock" error when using "Save as...". Does it only happen after a failed "Save as..." or each time you try to do "Save as...". Also do you only have this when saving to a network partition or always ?

3. When you were using "Save as..." to save to xml the last time, were you trying to overwrite an existing file ?

4. And how did you start ? Did you create a new file, or opened an existing one ? Is it the same file your are trying to overwrite ?

I hope this isn't taking you away from more important problems.  I have a work around that is not too painful and apparently, nobody else has reported this.  At any rate, here are my answers:

1. your understanding is correct and mount uses smbfs

2. Before 2.3.17 and 2.4.0 I did not try to save the data file to sqlite3 on the XP server.  I stayed with xml.  I always got the 'lock' error and just accepted it with no apparent degradation.  I almost never used 'save as' since GnuCash took care of managing the file names with time stamps.  I have three disks on my machine and have no problem with either xml or sqlite3 saving files to any of these disks.  This is true for new files (save as) or simple saves to existing files.

3. No, it was a new file name.

4. I started by opening the sqlite3 version of the data that I have stored on my machine.  'Save As' is to the netword share.  I have no problem staying on my machine.  I can open xml files on the network share and can save them.  Save As fails.  If I try to open a sqlite3 data file on the network share, GnuCash crashes.

(In reply to comment #6)
> I hope this isn't taking you away from more important problems.  I have a work
> around that is not too painful and apparently, nobody else has reported this. 
Well there are several network related problems on Windows and I'm trying to figure out if this is a separate issue or a duplicate but with different/additional details.

Anyway, thanks for the feedback. The fact that the network drive was mounted with smbfs seems to confirm my findings in bug 352491, that GnuCash' lock handling doesn't work via smbfs.

Do you have a way to use cifs instead (using "mount -t cifs" instead of "mount -t smbfs" for example) ? That seems to clear the locking issues at least with xml files. If cifs works for the xml lock issues, can you please add a comment on bug 352491 ? That would be great for future work on that issue.

I'm afraid your fourth answer still confuses me.

> 4. I started by opening the sqlite3 version of the data that I have stored on
> my machine. 
Ok, understood

> 'Save As' is to the netword share.  I have no problem staying on
> my machine.
Ok, understood.

> I can open xml files on the network share and can save them. 
With a normal save, not save as that is.

> Save As fails.
You mean that Save As always fails ? For both xml and sqlite3 ? From your previous comments, I thought I understood that
-  Save As to sqlite3 on the network fails completely, but in a clean run you could Save As from sqlite3 to xml on the network (ignoring the non-blocking lock error for a while)
- But the Save As attempt of sqlite3 in sqlite3 to the network share messes up things so badly that you can't even try to save as xml without restarting GnuCash ?
- And even it messes things up that badly that your nautilus run as a user can't access the network drive anymore, only nautilus in superuser mode can.

> If I try to open a sqlite3 data file on the network share, GnuCash
> crashes.
You can't even open an sqlite3 data file that is stored on a network share ?

Is there anything in the gnucash.trace file after each of these failed actions ?
- If you open an sqlite3 file that is on the network share (which crashes your system)
- If you try to save as to an sqlite3 file on the network share (which results in a failed save) ?

Thanks for all the info.

Regarding confusion (and I hope this doesn't add any!):

open sqlite3 file on linux.  Save As to a new xml file on network results in a 0 byte .log file and no data file.  GnuCash is still stable.

open sqlite3 file on linux.  Save As to a new sqlite3 file on network results in a 0 byte data file.  GnuCash is still stable.

However, simply trying to open a sqlite3 file from the network is what crashes GnuCash.

I can not reproduce the failure in Nautilus with 2.4.0.  That was with 2.3.17 as reported in the original bug report.  Sorry.

The thing that crashes GnuCash is trying to open a sqlite3 file from the network.  I can however both open and save an xml file on the network.  Save As for an xml that I have opened on the network results in a 0 byte data file.

I could not find a gnucash.trace file on my machine.  This could be because there wasn't one the last time I ran updatedb.  Where should it be?

Thank you, this does indeed clear things up. That is, it clears up what you did and at what point things go wrong. I don't know what the exact problem is and how to solve it unfortunately.

I would like to believe that the first two failures you describe are caused by the use of smbfs to mount your network drive instead of cifs. Is cifs available on debian as a partition format to mount ?

That gnucash crashes when reading an sqlite3 file from the network could also be caused by smbfs, but is in a totally different part of the code, so it will have to be investigated independently. Anyway, the mount-with-cifs test might give some more insights already.

I'm glad the nautilus thing is gone. We can ignore that then.

About the trace files: gnucash creates this on each run, by default in /tmp/gnucash.trace. Since it is recreated on each run, you should make a copy of the file if you want to share it here before running GnuCash again. Otherwise you will only have the trace of the last GnuCash run.

So in summary here are my questions:
1. Can you add the trace files as attachements for
a. save as to the network as xml
b. save as to the network as sqlite3
c. open an sqlite3 file from the network

2. After that, can you try to use cifs instead of smbfs to mount your Windows XP share and see if that makes a difference ?

Thank you for all your feedback.

Oh and did you by any chance have the save as to network problems with the older 2.2.9 version as well ? Obviously that one only had the xml option.

Just wanted to let you know that I won't be able to try anything most of today as I will be away from my machine.

I don't remember any 'save as' problems with 2.2.9.  I did consistently get the 'can't obtain lock' message on open; but, I just ignored it.

Created attachment 179450 [details]
first trace file

Created attachment 179451 [details]
second trace file

Created attachment 179453 [details]
3rd trace file

Created attachment 179454 [details]
last trace file

First, regarding smbfs vs cifs. I have given you misleading information. When I told you that the network share was mounted as smbfs it was because I looked in my /etc/fstab file. I was just about to change it to cifs; but, decided to first run a mount command. As it turns out, the share is mounted as cifs according to mount.

I checked for gnucash.trace after a simple run using sqlite3 data on my machine, i.e, no windows shares involved. Looks like there is a warning regarding libglade. My version of that is 1:2.6.2-1. And, also a critical message that probably has nothing to do with the issue you are pursuing here. At any rate, it is attachment gnucash.trace1.


Next, I tried to open the sqlite3 data on the network share. As usual, gnucash crashed. The trace file is attached as gnucash.trace2.

'Save As' to the network as an xml version resulted in a trace which looks exactly like a normal run on my machine. However, the only change on the network is a 0 byte .log file. This trace is attached as trace_to_xml.

'Save As' to the network as sqlite3 resulted in a trace which shows the lock problem. This trace is attached as trace_to_sqlite3.

Hope this all helps. But if not, ask away. . .

(In reply to comment #17)
> First, regarding smbfs vs cifs. I have given you misleading information. When I
> told you that the network share was mounted as smbfs it was because I looked in
> my /etc/fstab file. I was just about to change it to cifs; but, decided to
> first run a mount command. As it turns out, the share is mounted as cifs
> according to mount.
> 
Hmm, I don't know enough about Debian's internals to draw any conclusions from this. cifs and smbfs are normally different kernel modules. So if you set smbfs in /etc/fstab and mount reports cifs then
- either Debian has set smbfs as an alias for cifs
- mount -a ignores the smbfs request and uses cifs anyway (a variant of the above)
- or mount is lying to you and really has used smbfs, but reports cifs

Unfortunately this doesn't bring us any closer to the smbfs-vs-cifs-is-the-cause thingy :(

> I checked for gnucash.trace after a simple run using sqlite3 data on my
> machine, i.e, no windows shares involved. Looks like there is a warning
> regarding libglade. My version of that is 1:2.6.2-1. And, also a critical
> message that probably has nothing to do with the issue you are pursuing here.
> At any rate, it is attachment gnucash.trace1.
> 
Yes, these warnings and critical are unrelated. But it makes for a good reference trace for the others.
> 
> Next, I tried to open the sqlite3 data on the network share. As usual, gnucash
> crashed. The trace file is attached as gnucash.trace2.
> 
I actually managed to recreate a similar situation, although I didn't get a crash. GnuCash just hangs while loading. Perhaps I didn't wait long enough.

Interestingly though, while trying to set up a share on my Windows XP test machine, I found an option for mount.cifs that may help a bit already: nobrl

From the mount.cifs man page:
 nobrl
    Do not send byte range lock requests to the server. This is necessary for
    certain applications that break with cifs style mandatory byte range locks
    (and most cifs servers do not yet support requesting advisory byte range
    locks).

I tried setting that option while mounting my share, and now I can load an sqlite3 file from the share. No crash and I can make changes just fine.


> 'Save As' to the network as an xml version resulted in a trace which looks
> exactly like a normal run on my machine. However, the only change on the
> network is a 0 byte .log file. This trace is attached as trace_to_xml.
> 
Do you mean that the new file was saved successfully then, but the .log file was 0 bytes ? Above you stated the save as of xml to the network didn't result in a saved file. Just checking to be sure we're not chasing ghosts...

> 'Save As' to the network as sqlite3 resulted in a trace which shows the lock
> problem. This trace is attached as trace_to_sqlite3.
> 
The problem went away when mounted with the nobrl option as well here.

> Hope this all helps. But if not, ask away. . .

Apart from the above clarification regarding save as with xml, can you test what happens if you mount the share with the nobrl option ?

One reason the share is mounted cifs is that I don't have an smbfs module loaded and I do have a cifs module!  I guess Debian makes the substitution just fine.  In /etc/fstab I changed smbfs to cifs.  I then mounted with the nobrl option.

I can now open, save, 'save as' fine as long as all files are sqlite3.  Changes seem to be handled as expected.  The gnucash.trace files don't have any of the locking problems shown any longer.  

Save As to xml results in a stable GnuCash but only a 0 byte .log file on the network server.

BUT NOW. . .
Before I open a bug report I thought I would let you tell me I am doing something wrong.  Staying with only sqlite3 files.  I have been using fooDB.gnucash on my machine.  If I 'save as' to the network as foobDB.gnucash it shows up fine on the server.  If I make changes before the 'save as' they are recorded fine also.  If I open another file on the server, still OK.  If I reopen the foobDB.gnucash file, again all is well.  If I check the 'recent files' list the order of files makes sense given the activity of opens and saves.  Close GnuCash.  Restart GnuCash and the original fooDB.gnucash is opened and not the last file that I had had opened.

Ok. I looked around some more regarding sqlite3 and cifs. There is a potential for locking problems in that combination although most threads I found on the web seem to assume these problems are fixed. I have my doubts, given what we see here.

It seems that if the server runs samba, it works. If the server runs Windows (XP or Vista), there are locking problems unless you specify the "nobrl" option when you mount the share. Note that in principle specifying "nobrl" makes the file vulnerable to corruption in case of simultaneous access. Since we don't support that anyway (yet), this is no problem at this time.

There is a closed bug in the samba bugzilla database regarding this [1]. I have added a comment there to hear the experts on this.

In any case, this is clearly something outside the scope of GnuCash. I will add a note to the Windows wiki or to the FAQ regarding this problem and how it can be worked around. There isn't much more we can do.

Regarding the 0 byte .log files, I have no idea why that is. And to be honest, I don't feel like reseaching that part as IMO the log mechanism is very flawed anyway as it is right now (you can search bugzilla for other bugs regarding this) and nobody seems interested in fixing it. If you think it's important enough, I would propose to report it in a separate bugreport and keep this one clearly for the sqlite3 issue.

And about the history issue, please file another bugreport for that. My guess is it's unrelated.

[1] https://bugzilla.samba.org/show_bug.cgi?id=5994

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=637886. Please update any external references or bookmarks.