Main menu
You are here
Archiving can cause data loss
Fortunately for me, I have an up to date backup so there's no data loss. However, I did just discover a serious issue which I'll describe in the scenario below. Granted, the "perfect scenario" would have to exist in order for this to play out but in my case, it did.
Before archiving, I had a directory containing work I envisioned for a future album. Let's just say the album's name was intended to be "foobar"
/data/music/foobar/stuff
/data/music/foobar/more_stuff
/data/music/foobar/even_more_stuff
Time goes on and I forget all about this. Suddenly, I decide to name the current song I'm working on "foobar". Up until now, this song didn't have a title and I've just been calling it "idea4". I explained this very real-world scenario in a previous thread where I discussed how difficult it is to rename a piece of work in a sane fashion.
OK so I'm in my "idea4" song and I decide I'll begin the renaming process by making use of the archive feature. Upon making use of "save as", I select /data/music as the location, select the archive format, and name the file "foobar.qtz". Despite this being totally non-intuitive, I just know from experience that I need to select the root of where I want the archive to be decompressed in order to end up with everything inside a directory of /data/music/foobar
Then I open the archive in Qtractor and back at a shell, I look at the contents of /data/music/foobar. Ah good, everything is there BUT I also see all the other data I forgot existed in the already existing directory! OK, no problem. I should just be able to close Qtractor so it cleans up after itself. Had I thought about it just half a second longer, I would have realized it's actually going to delete the directory despite the fact all contents are not associated with the Qtractor project. Yep, the directory was blown away and I lost all the data that once existed in that location.
OK so basically, there are a few opportunities to improve things (assuming the whole ability to rename a project gracefully is still not going to go under the knife for a total refactor)....
1. When saving as, a simple check could test for the existence of a directory that matches the filename entered into the dialog box. Upon finding a match, Qtractor would prevent the save operation from taking place and scold the end user appropriately.
2. As a fail-safe when working with a file that has been opened from an Archive, Qtractor's cleanup routine could be changed to operate as follows:
* Iterate over all files known to the project; deleting each
* When it's time to rm -fr the actual directory, check to ensure it contains no files/directories (dirs are just files actually)
* Only delete the directory when the above test shows it is safe to do so
All the best
re. Archiving can cause data loss
wait,
re.Then I open the archive in Qtractor and back at a shell, I look at the contents of /data/music/foobar
on the moment an archive (.qtz) is to be opened, it actually checks whether a sub-directory with the very same file-name ("foobar") already exists, *always* prompting you if positive to erase all its contents *before* the extract operation begins... staring at the case where you still seeing old files in that purposed extraction directory probably means that you cancelled the load archive operation, and ended with a empty session (something that you seem to omit or maybe I'm wrong).
however,
re. 1. When saving as, a simple check could test for the existence of a directory that matches the filename entered into the dialog box. Upon finding a match, Qtractor would prevent the save operation from taking place and scold the end user appropriately.
sounds like a good idea, one that would possibly prevent the above scenario, whenever you answer positively to erase the existing directory (maybe _accidentally_? :))
thanks && cheers
Hello again
Hello again
I don't believe I ended up with a empty session as I'm fairly certain my arranger window had clips inside of it (pointing to the .mid files I saw in the exploded directory). I also know I was never prompted as I certainly would have remembered that. Perhaps this check used to exist at some point but no longer does?
All the best and Happy Halloween
re. I was never prompted...
maybe some time before you checked the "Don't ask this again" ? or/and you turned off option [View > Options... > General >] Confirm archive removals ?
I'd suggest to turn it back on, as to avoid future missteps... better yet, turn on all confirmation options (all are on by default; you probably turned'em off explicitly sometime) until you are fully comfortable with all the workings?
hth.
cheers
I just checked and you are
I just checked and you are correct that I had disabled that option at some point. However, I still maintain the position that a given application should never manage or delete any data that is not entirely within its domain. In other words, the confirmation is really just a stop-gap indicating a larger problem with the overall work-flow.
All the best
re. not entirely within its domain..
well, you are generally and ideally right of course...
caveat is, qtractor doesn't have a domain -- never had, never will -- all files are general standard files, be that audio or MIDI files, whatever... none are actually claimed as qtractor's property... they maybe all shared across and to any other application, domain or else... even though you may create some in premises, so to speak, they are just yet another file-system entity, not quite owned by itself or any particular qtractor session, file or directory for that matter.
you actually found a corner case where qtractor may well cause data loss: like naming a .qtz file to an existing directory or folder name in where it will get saved... while opening that archive later may indeed replace that former directory mercilessly... besides, I am thankful for your spotting this potential hazard... it should and will be addressed in a near future, rest assured ;)
thanks again
cheers
All good and I appreciate the
All good and I appreciate the discussion.
re. When saving as [zip/archive (*.qtz)]...
re. When saving as [zip/archive (*.qtz)], a simple check could test for the existence of a directory that matches the filename entered into the dialog box. Upon finding a match, Qtractor would prevent the save operation from taking place and scold the end user appropriately.
done in qtractor >= 0.9.24.8git.a1c2e8
cheers && thanks again
Awsome
Awesome
Add new comment