On Wed, Mar 25, 2009 at 3:29 PM, Markus Meyer <meyer@...> wrote:
> 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 . 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.
>  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.
I'm sort of split on this...
I commonly copy files to a .bak extension when I've got something working,
but want to make some sort of experimental change and don't want to risk
losing the progress I've made. You would have to come up with some way to
agree that the .bak file you are deleting corresponds to a particular .aup
file. Reasonable assumptions can be made, like the filename is the same
other than the .bak/.aup, but that isn't guaranteed to always be "safe".
I do like the idea of informing the user that they've opened a .bak, however
some more advanced users may get annoyed at this if they are like me and
have backed their project up in this fashion. If you go this route, may want
to add a "Don't show me this again" check box to it.
As for refusing to open anything other than .aup, I'm not a huge fan of
this, simply because coming from a strong UNIX/Linux background, I believe
that an application should be smart enough to figure out what type of file
it is working with, regardless of the file extension.
Just my two cents, good luck!
Zach J. Elko