[Audacity-devel] .bak files confusing users
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
|
From: Markus M. <me...@me...> - 2009-03-25 19:29:35
|
Hi,
I just wanted to talk about something that seems to happen sometimes to
users in the German forum regarding the .aup.bak files Audacity creates
by default. It seems that users are sometimes confused by them and open
them instead of the .aup files [1]. Opening the .bak files usually
triggers the "orphaned blockfiles" message. When users do the
recommended thing ("delete files (usually safe)") and later notice their
mistake, they close the project and try to open the .aup file instead,
but the data files which were previously mistakenly recognized as
"orphaned blockfiles" are already gone, leaving the user with a damaged
project. If, on the other hand, the user does not recognize his mistake
at first and then saves the project, another backup file is created
("test1.aup.bak.bak"), adding to the confusion.
I can think of three possible fixes for this scenario:
1. Audacity should check if the project it tries to open really has the
ending ".aup" and should refuse to open it if it has another ending.
2. Audacity should check if the project it tries to open specifically
has the ending ".bak" and should refuse to open it in this case and show
a message instead which educates the user about the fact that he is
trying to open a ".bak" file instead of the "real thing".
Naturally, 1 and 2 can be combined in lots of ways ;-)
3. We just get rid of the .bak file. I actually do not see the value of
the .bak file because Audacity, when saving an .aup file will delete
blockfiles it does not need anymore anyway. So I'm not sure whether it
makes sense to keep a .bak file, but when the user opens this .bak file
he will be notified that the .bak file references data which does not
exist anymore anyway. I can think of no use case where having a .bak
file after accidentially deleting e.g. a track in Audacity will help the
user to restore the data.
Of course, we should not simply overwrite the old .aup file when saving
but we could, e.g., move the old .aup file to .aup.bak and delete
.aup.bak after the .aup file has been written successfully and was
closed (and possibly fsync()ed).
Please let me know what you think. I'm planning to implement either 1,
2, or 3 if a consensus is reached.
Markus
[1] Windows makes this easy, asking the user to "specify the program
with which this file should be opened" in Explorer, if the user then
chooses "Audacity", the file will open in Audacity despite being a .bak
file. The fact that Windows does not show extensions by default also
adds to the confusion. If both .bak and .aup files are associated with a
program, Windows will show e.g. "project.aup" as "project" and
"project.aup.bak" as "project.aup". If e.g. the user has heard from
somewhere that he needs to open the "project.aup" file, he opens exactly
the wrong file.
|