GothenburgBitFactory
[TW-1393] Database corrupted after running task if the disk is full
Tobiasz Karoń on 2014-08-17T10:45:33Z says:
I've run task to see my "next" list. It printed it fine.
I run it again to mark some task as done, but this time I got a strange message:
Taskwarrior no longer supports file format 1, originally used between 27 November 2006 and 31 December 2007. in /unfa/.task/pending.data at line 80
What happened? This is my theory: task tried to rewrite the pending file to update my tasks, but instead of rising an exception and halting the procedure, it wrote only a part of the file, because the disk was nearly full.
I think this behaviour is highly erroneous and causes severe data loss, where it can easily be avoided.
Migrated metadata:
Created: 2014-08-17T10:45:33Z
Modified: 2017-02-19T13:28:33Z
Paul Beckingham on 2014-08-31T18:48:14Z says:
This will be solved by a simple two-stage atomic write.
Pavel Šimerda on 2015-08-25T15:14:29Z says:
It's been some time since reported. Has it been fixed?
Paul Beckingham on 2015-08-26T09:13:29Z says:
If the issue remains open, then no, not fixed.
Pavel Šimerda on 2017-02-01T22:33:13Z says:
I'm sorry but you are forcing me to write my own reliable tool. Not being able to do something as simple as two-phase file replacement where you (1) create the new data file and (2) move the new data file over the old one, all that in a couple of years, makes your project essentially dead for me.
I lived without a task software for the time being but now I would need something that doesn't die so easily.
Maybe if you gave me some support at the right time I would be able to help, but now it's pretty clear that you don't care anymore.
Goodbye.
Tomas Babej on 2017-02-02T06:42:10Z says:
I would object to the notion that we do not care - on the contrary, we are always happy to accept contributions (and work with people to get them to the mergeable state). There is documentation (i.e. DEVELOPERS file), we provide support channels (devel list, IRC channel, mail). Currently we have 68 contributors that were able to get their patches in. I don't think the problem here was in the lack of support of contributors from our side.
Some issues take longer time to fix, some issues are fixed immediately. We're an volunteer driven project. No paid employees. Quickest way to get something fixed is contributing a patch, not contributing a rant.
Pavel Šimerda on 2017-02-19T13:28:33Z says:
I see. I'm the last person who would like to rant instead of providing a patch.
Just for the record, as we already spoke on IRC. In all my projects in the past I follow the general rule of thumb to replace data by first writing a correct new version and only then drop the old one. When I look in the code, taskwarrior seems to use a File class that opens files for reading and writing and appends by seeking. That doesn't look like a good practice. The logging code, for example, just neds to open, write and close, no reading, no seeking.
The database code, on the other hand, uses plain text files and I'm pretty sure you generally don't need to read+write+seek text files. To parse the data, you just nead to open-read-close, to write the data to a new file, you just need open-write-close, to replace a file, you basically need to open(tmp)-write-close-rename.
I looked in the code. The changes aren't probably difficult. But what makes me feel bad about the potential changes is that we would be changing code that is, in my humble opinion, simply wrong. We shouldn't IMO be opening for read-write any text files at all in taskwarrior but I can stand corrected.
I've run into this too. In my case viewing the task list while the disk was full and having it try to create new recurring tasks resulted in all tasks in the database being erased.
As an interim solution, I've put a wrapper around the task command that simply refuses to run it if the disk doesn't have at least 50MB of free space remaining. Not the technically "best" solution, but might be quicker to implement in the tool itself than atomic operations.
