DATA LOSS - deletes temp file before open shot has finished with it

Bug #1183321 reported by Tim Abell
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Kazam Screencaster
New
Undecided
Unassigned

Bug Description

Just completely lost the video I'd carefully recorded, a bloody awful first experience with Kazam. Not happy. <sadface>

To reproduce this:

 * Record some screen activity with kazam
 * (Note the appearance of a /tmp/kazam_*.movie file)
 * Select "Open with: 'OpenShot Video Editor'" (the only editor available by default on Ubuntu 12.04 LTS
 * In OpenShot save the project (File > Save Project), defaults are fine for this reproduction.
 * As a naive user, think that your valuable recording is now safe, however openshot has only saved project info not the raw video data.
 * Close OpenShot
 * Close Kazam (including the one in the activity area), note disappearance of temp file, __losing the recording__!
 * Re-open OpenShot
 * Re-open the project (File > Recent Projects > *.osp)
 * Get the dreaded message "The following file(s) no longer exist. /tmp/kazam_*.movie"
 * Your data is now gone, and your kazam user is now furious.

(in the file names above "*" is replaces with kazam's random file name string)

Although you could argue that openshot is in some way responsible for this I think the blame is squarely in Kazam's court as Kazam has supplied a file path to openshot which openshot cannot be expected to know will be deleted at an arbitrary point in the future by an apparently innocuous user action.

Even if you are using openshot, kazam should put the video somewhere persistent like ~/Videos/kazam/ and not in tmp/ so they don't get lost. Putting such valuable user data in a volatile location is just asking for data loss imho. What happens if the power fails? /tmp will be lost, along with the user's recording! Worse, the user might close kazam mid editing in openshot, then what would happen?

Please consider this a critical bug suitable for back-porting to the LTS release of Ubuntu as it is a user-data loss bug.

Tags: data-loss
Revision history for this message
Tim Abell (tim-abell) wrote :

Incidentally I did get there in the end, and here's the result http://youtu.be/lT4vTP4Dn-c but I still think this bug needs addressing as it's really rather nasty.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.