Time Drive

Catching, Logging and Providing Notifications of Errors

Registered by Rob Oakes

Through testing, it has been discovered that duplicity can fail silently without providing the user with any feedback on why it may have failed. For this reason, Time-Drive should include a log and error notification system.

Part of this has already been implemented through the usernotifications class. But additional classes are needed to detect when duplicity has failed and commit that information to an internal log. This log might be viewed from the settings pane (under the advanced tab?), and offer rudimentary suggestions on how to correct the error.

Blueprint information

Status:
Complete
Approver:
Rob Oakes
Priority:
High
Drafter:
Rob Oakes
Direction:
Needs approval
Assignee:
Philippe Delodder
Definition:
Approved
Series goal:
Proposed for 0.3
Implementation:
Implemented
Milestone target:
milestone icon 0.3
Started by
Philippe Delodder
Completed by
Philippe Delodder

Sprints

Whiteboard

Logging and Error Notifications. Overall Goals:

* The ability to notify the user of an exception or problems if the Gui is loaded, or cache it to a log if it is not (e.g. should an error happen during a cron job).
* If the error happened during a scheduled job, notify the user of that error or automatically load the log the next time that the Gui is run.
* Better process the output from the _exec command and and create easy to understand error messages that suggest an appropriate action.

Specifics:

* (DONE) Storage Location. I think that $home/.cache/time-drive/ would be fine for a storage location. However, I am somewhat concerned that .cache is primarily a Linux/Unix convention. Does either python or Qt include a class similar to QSettings which would allow for the cache to be stored in a platform appropriate location? For example, ~/Library/AppData/Time Drive on Mac OS X or C:\Users\Username\AppData\Local\Time Drive on Windows? (A quick look at the Internets and a few other programs -- duplicity, Deja-Dup -- appears that such a library may not exist as they handle this manually.)

* (Mostly Done) Fatal Error GUI. As noted above, I think that if the Gui is running, we should pause the operation, notify the user and ask what should happen next: either retry, abort backup or skip folder, or something else appropriate. (Needs Discussion) This also raises another point, should a backup be aborted, there is a little bit of maintainance that should happen on the archive (call duplicity clean, for starters. I'll discuss this more below.)

* (DONE) Fatal Error Batch. If the Gui is not running then it should be written to the log and the user notified the next time that the Gui is run.

(?)

Work Items

Nearby

This blueprint contains Public information 
Everyone can see this information.
Edit subscription

Subscribers

No subscribers.