Automatically installs Taskwarrior, Taskserver (TODO: and Timewarrior). This project aims to support automated installation of all Taskwarrior hook scripts, configuration flavours etc. with a single command.
GNU Affero General Public License v3.0
17
stars
7
forks
source link
`FillBacklogTasks.manageBacklogFilling` writes to `backlog.data` which can cause conflict with taskwarrior commands. #19
<p>Between <code>lines = readLines(backlogPath, backlogFileName);</code> and method <code>CreateFiles.writeFileContent</code>, the user has the time to enter taskwarrior commands that should imply changes in file <code>backlog.data</code>.</p>
However currently the changes made in that timeframe are lost, since after the delay between reading the backlog.data file and writing the modifications to it, the modifications are written to backlog.data, even though the modifcations did not yet take those user commands into account.
Two solutions could be:
Temporarily block access to the backlog.data file while modifications are being computed.
Deleting/temporarily renaming the backlog.data file, reading it, computing the modifications, scan if there exists such a backlogfile:
if there does not exist such a backlog.data file:
a Write the modifications to it,
if there does:
2.a Delete/temporarily move that new backlog.data file, copy it's lines (except for the tw uuid) and append them to the bottom of the modified backlog.data and again check if there exists such a backlog.data file (step 1): (where the modifications and the new lines from the new backlog.data file are written together in 1.a)
If there does, just repeat step 2. until the user did not enter any taskwarrior commands that modify the backlog.data file in between modification processing time.
Todo: Find out what happends if the user command changing backlog.data and sorting read backlog.data action are extremely close together, e.g. that the user changes are still being written while the custom sorting read backlog.data action is being sent already. (And vice versa). To determine if there can occur any loss in user modifications in the very slim chance of simultaneous occurrence.
However currently the changes made in that timeframe are lost, since after the delay between reading the
backlog.datafile and writing the modifications to it, the modifications are written tobacklog.data, even though the modifcations did not yet take those user commands into account.Two solutions could be:
backlog.datafile while modifications are being computed.backlog.datafile, reading it, computing the modifications, scan if there exists such a backlogfile:backlog.datafile:2.a Delete/temporarily move that new
backlog.datafile, copy it's lines (except for the tw uuid) and append them to the bottom of the modifiedbacklog.dataand again check if there exists such abacklog.datafile (step 1): (where the modifications and the new lines from the newbacklog.datafile are written together in 1.a)If there does, just repeat step 2. until the user did not enter any taskwarrior commands that modify the
backlog.datafile in between modification processing time.Todo: Find out what happends if the user command changing
backlog.dataand sorting readbacklog.dataaction are extremely close together, e.g. that the user changes are still being written while the custom sorting readbacklog.dataaction is being sent already. (And vice versa). To determine if there can occur any loss in user modifications in the very slim chance of simultaneous occurrence.