Do I remember correctly that you're using the SQL backend? That works a bit differently because there's no way to have a lock file if you're connected to a DB server. Instead of a lock file it has a lock table inside the database. If you copy the database (and with SQLite3 it looks just like a file) when there's a lock record in the lock table then GnuCash will put up the "unable to obtain the lock" dialog box.
Regards, John Ralls > On Jan 20, 2021, at 6:24 AM, Chris Green <c...@isbd.net> wrote: > > On Wed, Jan 20, 2021 at 09:04:52AM -0500, Derek Atkins wrote: >> Hi, >> >> On Wed, January 20, 2021 8:33 am, Chris Green wrote: >>> On Wed, Jan 20, 2021 at 08:23:23AM -0500, Derek Atkins wrote: >>>> Hi, >>>> >>>> The lock file is created in the same directory as the data file. >>>> Is that directory not writeable? That would cause the error. >>> >>> The directory is definitely writeable and there definitely isn't any >>> sort of lock file in the directory:- >>> >>> chris$ cd tmp/pcc/2020 >>> /home/chris/tmp/pcc/2020 >>> chris$ ls >>> building.gnucash building.gnucash.20210120121447.log general.gnucash >>> chris$ ls -al >>> total 504 >>> drwxrwxr-x 2 chris chris 4096 Jan 20 12:14 . >>> drwxrwxr-x 3 chris chris 4096 Jan 20 12:13 .. >>> -rw-r--r-- 1 chris chris 212992 Jan 20 12:14 building.gnucash >>> -rw-rw-r-- 1 chris chris 381 Jan 20 12:14 >>> building.gnucash.20210120121447.log >>> -rw-r--r-- 1 chris chris 290816 Jan 20 12:14 general.gnucash >>> chris$ gnucash general.gnucash >>> Found Finance::Quote version 1.49. >>> chris$ >>> >>> The above sequence pops up the can't create lock file error. >> >> The "cannot obtain lock" error has multiple causes. Have you checked the >> Tracefile to see if there is anything printed that might suggest which >> error is happening? >> >> The error occurs when: >> 1) There is a lock file already there, or >> 2) There is NOT a lock file already present, but gnucash cannot create a >> new lock file >> >> If you're in case #2, then you won't see a lock file listed. >> >> Is your disk full? What do you get from: >> df /home/chris/tmp/pcc/2020 >> df -i /home/chris/tmp/pcc/2020/ >> > No, my disk isn't full:- > > Filesystem Type 1M-blocks Used Avail Use% Mounted on > /dev/nvme0n1p2 ext4 48174 13344 32315 30% / > /dev/nvme0n1p3 ext4 896193 308524 542077 37% /home > /dev/sdb1 ext4 10016 181 9307 2% /boot > /dev/sdb2 ext4 109596 27675 76313 27% /scratch > /dev/sda1 ext4 938772 225049 666014 26% /bak > >> Also, what kind of filesystem underlies /home/chris/tmp/pcc/2020 ? >> > Standard linux ext4 (as you can see above). > > >>>> If GnuCash cannot create (and lock) the lock file then it will throw the >>>> error. >>>> If you are SURE that there is not another process running, you can "Open >>>> Anyways" and that will clear the error. >>>> >>> Yes, I realise that, but it's not "right". :-) >> >> It depends on the underlying error. If the lock file is actually there >> but, say, gnucash crashed, then "Open Anyways" *is* the right solution. >> Obviously that's not the case here. >> > Yes, OK, there are cases where "Open anyway" is the right solution, > but there seems to be something else going on here. > > >>>> NB that gnucash may mix the metadata for two versions of the same-named >>>> file located in different directories. The GCM file does not contain >>>> the >>>> file location information. >>>> >>> I'm not quite sure I follow that, I do have general.gnucash in two >>> different places. Are you saying that this may cause problems and >>> that I should rename my 'previous year' accounts to (for example) >>> general2020.gnucash as well as moving them to a suitably named >>> sub-directory? >> >> If you open a file foo.gnucash, gnucash creatres a metadata file >> foo.gnucash.gcm in $HOME/.local/share/gnucash/books. Now, if you copy >> foo.gnucash from DIR1/foo.gnucash to DIR2/foo.gnucash, when you open >> DIR2/foo.gnucash it will use the same foo.gnucash.gcm file, because DIR1 >> vs DIR2 is not encoded anywhere. >> >> So yes, IF you decide to archive data files, you should change the name. >> > OK, that makes sense, thank you. > > >> NB: there is no need to start over every year; GnuCash hapily accounts for >> multiple years of data and reports know how to handle that. >> > That might make sense for me, I'm not quite sure. It's not a very > busy system so I can go for a month and see if I can then generate > what the auditor requires for 2020. If it all goes wrong I can undo a > month (I have daily incremental backups). > > -- > Chris Green > _______________________________________________ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using Nabble or Gmane, please see > https://wiki.gnucash.org/wiki/Mailing_Lists for more information. > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.