GNOME Bugzilla – Bug 352491
GnuCash does not manage .LCK/.LNK files on Samba share
Last modified: 2018-06-29 21:11:43 UTC
Please describe the problem: I have been storing my GnuCash files on a Samba share since I began using it in 1.8.x. I recently upgraded to 2.0.1 (my own build) on my SuSE 10.0 desktop. Each time I open the program, I get this message: GnuCash could not obtain the lock for /home/des/H Drive/Dougan Consulting Group/Banking/FY 2006 (GnuCash 2 version). GnuCash will create a .LNK file in this directory when told to go ahead and open the existing file. It will leave the file there on a clean close, and will display the above-noted message whether there is a .LNK there or not. Copying the data file to a local directory opens and closes with no error messages or files left over. Steps to reproduce: 1. Open GC on a Samba-mounted (via smbmount) directory. 2. Message is displayed. 3. Override message, use GC, and then close. a .LNK file is left behind. Actual results: As noted. Expected results: No .LNK files unless GC crashes. Does this happen every time? Yes. Other information: Program works very well otherwise.
There was one other bug related to samba share, bug#345913, but this was solved by ignoring a failed chmod(). In this case obviously the .LNK file fails to be removed correctly, but so far I have no idea why.
Still seeing exact behavior in version: GnuCash 2.0.5, Built 2007-09-24 from r15617.
Still seeing this behavior with GnuCash 2.2.1, Built r16462 on 2007-10-03 (Also, tried same version with sshfs and after saving the file, the gnucash database file gets deleted! Make sure you have backups).
*** Bug 611920 has been marked as a duplicate of this bug. ***
From bug 611920, this problem still exists in 2.2.9. Apparently it works fine on Windows, but not on Mac OS X or linux (copied from forementioned bug): * on Windows the .LCK file is removed properly * on Mac OS the .LCK file is left in place * on Ubuntu the .LCK is left in place but its mode is changed from 000 to 002; also leaves a .LNK file in place with the same mode changes
I have been doing some more tests. The exact protocol used to mount the network share seems to be important. * Server is Centos 5 - Client is Mandriva 2010.0, using mount -t cifs ... => No issues. The proper LCK and LNK files are created, file can be edited and saved directly on the share * Server is Centos 5 - Client is Mac OS X Snow Leopard (which uses the smbfs instead of cifs to mount the share) => Only a .LCK files is created and left behind. The file can be saved directly to the share. Perhaps others can chime in with more details as well. It would also be useful if you could start gnucash from the command line as "gnucash --debug" try to reproduce the problem and attach the /tmp/gnucash.trace file to this bug.
And it may be that not only the client side, but also the server side plays a part. I don't have any clear "evidence" yet, but my investigations for bug 637886 showed that using Windows XP as server or Samba as server yield different results.
Geert, Is this still evident in SVN Trunk? I have done a fair amount of work with Samba/CIFS integration and I can say for sure that the Mac smbfs implementation is flaky at best. And yes, when comparing Windows to Samba shares there are a LOT of differences, Samba tends to be much more forgiving, while Windows shares put things on lock-down. You said you are using a Windows XP machine for the CIFS share - what Service Pack is installed? Although from your 2010-06-08 post it sounds like the Mac problem is evident with a Samba server as well. Are any of the machines on an Active Directory network or just standalone systems? Can you post an example of your mount options for the Mac (with user/pass masked of course)? Are you absolutely, 100% _SURE_ that GnuCash has completely released all file handles to the .LCK file before trying to delete it? Otherwise the Mac will almost certainly not allow it to be deleted. I don't know if there is some way you can check for open handles to the file immediately prior to deletion for debugging purposes, but I would definitely recommend verifying this if you can. Is it possible for you to point me in the right direction to the code responsible for the .LCK files? I can't promise I will have any solutions but it may help to have another set of eyes on this. Smbfs on the Mac can be a real PITA. Thanks, -Tim
Tim, I'm trying to rebuild the latest svn revision on OS X to rerun some tests. But I'm stuck on a dependency error for now. I'll keep you updated once I've got some more details.
I've taken my time to get back to this one. All tests below are performed with xml data files. There may be other results with the sqlite3 backend. A. Using Windows XP as server: ------------------------------ - Client Mac OS X (Snow Leopard): A .LCK lock file is created when opening a the datafile. When GnuCash quits, the lockfile is nicely removed. There's no .LNK file. - Client Fedora 14: Mounted share with mount -t cifs <share-on-XP-server> /mnt -o uid=<uid>,gid=<gid>,username=<username> With this setup, GnuCash fails to load or save a file to the windows share. It has to be a GnuCash only problem. I can copy files via the command line just fine. And copying the file it fails to load to a local drive, it does open the file with no problems. The error I get is "No suitable backend found for <my file>" B. Using Centos 5/Samba as server: ---------------------------------- - Client Mac OS X (Snow Leopard): A .LCK lock file is created when opening the data file. When GnuCash quits, the lockfile is nicely removed. There's no .LNK file. - Client Fedora 14: Both a .LCK and .LNK lock file are created when opening a the datafile. When GnuCash quits, both are nicely removed. I didn't test a Windows client at this point. If relevant I can do that test later. But anyway, there still seems to be some issue. I'm not sure if this is a Fedora problem or something with GnuCash on linux in general.
(In reply to comment #8) > Is it possible for you to point me in the right direction to the code > responsible for the .LCK files? I can't promise I will have any solutions but > it may help to have another set of eyes on this. Smbfs on the Mac can be a > real PITA. For your information, the function responsible for setting the .LCK file is gnc_xml_be_get_file_lock which is in src/backend/xml/gnc-backend-xml.c, line 115
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=352491. Please continue processing the bug there and please update any external references or bookmarks.