[Audacity-devel] Audacity 2.1.3 RC1 potential data loss

Confirmed on Windows and Mac.
I'm judging it a P1. We will need a respin of the RCs.

This is my fault for not reviewing an amelioration for Bug 1567
sufficiently carefully.

The problem is here in DirManager.cpp :

// You may think the loops above guarantee that all files we put
in the
// folders have been moved away already, but:
// to fix bug1567 on Mac, we need to find the extraneous
.DS_Store files
// that we didn't put there, but that Finder may insert into the
folders,
// and mercilessly remove them too.

CleanDir(
cleanupLoc1, wxEmptyString, _("Cleaning up cache
directories"), true);

cleanupLoc1 will be the original project rather than a cache directory
in the scenario Bill outlined.
The problem is NOT the _. It is doing a SaveAs of a project that has
been loaded or saved in the same session. You get the same result if
you create some data, Save with the name 'Foo' and then SaveAs with the
name 'Bar'.

The RC1s are dangerous, so I am removing them from FossHub right away.

--James.

Post by Bill Wharrie
If you “Save Project As” and append “_<anything>” (that is, underscore followed by any text) to the project name, the original project data folder will be deleted.
- new project
- Save Project As “MyProject.aup” (for example)
- make some content (I used 30 minutes noise so the save would take a few seconds)
- Save Project
- Save Project As “MyProject_edit.aup” (the underscore is the critical part) **in the same directory**
— the “MyProject_edit_data” folder is created and filled
— the “MyProject_edit.aup” file is created
— the “MyProject_data” folder **is deleted**!!!
This is a regression on 2.1.2.
— Bill
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Steve the Fiddle

2017-02-19 14:07:16 UTC

Ouch. Confirmed on Linux.

Steve

Post by James Crook
Confirmed on Windows and Mac.
I'm judging it a P1. We will need a respin of the RCs.
This is my fault for not reviewing an amelioration for Bug 1567
sufficiently carefully.
// You may think the loops above guarantee that all files we put
in the
// to fix bug1567 on Mac, we need to find the extraneous
.DS_Store files
// that we didn't put there, but that Finder may insert into the
folders,
// and mercilessly remove them too.
CleanDir(
cleanupLoc1, wxEmptyString, _("Cleaning up cache
directories"), true);
cleanupLoc1 will be the original project rather than a cache directory
in the scenario Bill outlined.
The problem is NOT the _. It is doing a SaveAs of a project that has
been loaded or saved in the same session. You get the same result if
you create some data, Save with the name 'Foo' and then SaveAs with the
name 'Bar'.
The RC1s are dangerous, so I am removing them from FossHub right away.
--James.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2017-02-19 17:13:13 UTC

Thanks, Bill for finding that, notwithstanding it was more general than
you thought.

It's really difficult if something like this gets past two developers.
Not knowing better, I assumed "cleanupLoc1" was explicitly and
only cache, especially given the string that followed.

The only chance of QA finding such a problem is testing a lot more
beyond the actual bug fix, which slows up resolution, or having
enough people testing builds with their normal workflows. Hopefully
the "testers' initiative" will help, if we can encourage enough interest/
convince users that builds between releases could be safe enough
for production. That "convincing" could be the hard part.

Gale

Post by Steve the Fiddle
Ouch. Confirmed on Linux.
Steve

James Crook

2017-02-19 17:39:14 UTC

Since that's exactly the mistake I made too, it's a very excusable
mistake :-)

Post by Gale Andrews
The only chance of QA finding such a problem is testing a lot more
beyond the actual bug fix, which slows up resolution, or having
enough people testing builds with their normal workflows. Hopefully
the "testers' initiative" will help, if we can encourage enough interest/
convince users that builds between releases could be safe enough
for production.

I think we really do need more people trying out (good) builds with
actual production use - if a little more cautiously than usual use perhaps.

Post by Gale Andrews
That "convincing" could be the hard part.

I think if a developer gets a reputation for adding cool and useful
features, there will be plenty of takers. Paul's voice work additions
are likely to be particularly popular.

Just for the record, we have a process problem to fix behind this bug.
Normally when moving from DEVEL-FIXED to CLOSED, particularly for a P1,
Gale spends significant time looking at the commit, makes guesses about
what the developer could have done wrong, and tests around the bug,
cases that might have been perturbed by the fix. In this case we as a
team voted to allow the P1 (bug 1567) through with a 'partial support on
Sierra' note in the release announcement. Therefore the P1 fix
(amelioration) did not even take the bug to DEVEL-FIXED, so neither me
nor Gale were looking at a DEVEL-FIXED to CLOSED transition and thinking
'oh thats good' or 'does-that-need-a-second-look?'

So a note to future me, is when there is (exceptionally) a P1 going
through to release, look to see if any of the fixes/ameliorations might
need rolling back.

--James.

Gale Andrews

2017-02-19 19:13:22 UTC

Since that's exactly the mistake I made too, it's a very excusable
mistake :-)

I think we really do need more people trying out (good) builds with
actual production use - if a little more cautiously than usual use perhaps.

Post by Gale Andrews
That "convincing" could be the hard part.

I think if a developer gets a reputation for adding cool and useful
features, there will be plenty of takers. Paul's voice work additions
are likely to be particularly popular.

It's a balance too, because as soon as HEAD moves on from that
build, they are not testing the latest code (until the next "alpha
pre-release").

And if the new feature isn't ready until release after next, not all of
them may move on to test a new "alpha pre-release" off HEAD.

Post by James Crook
Just for the record, we have a process problem to fix behind this bug.
Normally when moving from DEVEL-FIXED to CLOSED, particularly for a P1,
Gale spends significant time looking at the commit, makes guesses about
what the developer could have done wrong, and tests around the bug,
cases that might have been perturbed by the fix. In this case we as a
team voted to allow the P1 (bug 1567) through with a 'partial support on
Sierra' note in the release announcement. Therefore the P1 fix
(amelioration) did not even take the bug to DEVEL-FIXED, so neither me
nor Gale were looking at a DEVEL-FIXED to CLOSED transition and thinking
'oh thats good' or 'does-that-need-a-second-look?'

Yes, that didn't help. I was focusing on "did the fix remove some of the
1567 occurrences?" and the whole 1567 problem was taking a lot of
my time already.

And no-one else in QA was testing I think, because I was the only one
of us whose machine was showing the symptoms.

Post by James Crook
So a note to future me, is when there is (exceptionally) a P1 going
through to release, look to see if any of the fixes/ameliorations might
need rolling back.

Yes, well note to me too I suppose.

Gale

James Crook

2017-02-19 19:28:49 UTC

Post by Gale Andrews

Post by James Crook
So a note to future me, is when there is (exceptionally) a P1 going
through to release, look to see if any of the fixes/ameliorations might
need rolling back.

Yes, well note to me too I suppose.

Main thing is that we did catch it before release. Kudos to Bill that
we did.

--James.

Darrell Walisser

2017-02-19 17:48:03 UTC

Just wondering if anyone has proposed or been thinking about adding unit
tests or other test automation to Audacity. This bug strikes me as one that
could be added to a conventional unit test.

I've done a little digging and there are tools available to test the GUI,
either by interaction record/playback tools (totally decoupled from the
source code) or writing more conventional unit tests with (hopefully) a
library that hooks into wxWidgets. There are a few possibilities listed on
wxWidgets.org.

https://wiki.wxwidgets.org/Tools#Testing

And there is Audacity's own scripting system that could be used to test
some things as well and might encourage extending it to test even more
things (if that's desired!).

Post by Gale Andrews
Thanks, Bill for finding that, notwithstanding it was more general than
you thought.
It's really difficult if something like this gets past two developers.
Not knowing better, I assumed "cleanupLoc1" was explicitly and
only cache, especially given the string that followed.
The only chance of QA finding such a problem is testing a lot more
beyond the actual bug fix, which slows up resolution, or having
enough people testing builds with their normal workflows. Hopefully
the "testers' initiative" will help, if we can encourage enough interest/
convince users that builds between releases could be safe enough
for production. That "convincing" could be the hard part.
Gale

Post by Steve the Fiddle
Ouch. Confirmed on Linux.
Steve

If you âSave Project Asâ and append â_<anything>â (that is,

underscore followed by any text) to the project name, the original project
data folder will be deleted.

- new project
- Save Project As âMyProject.aupâ (for example)
- make some content (I used 30 minutes noise so the save would take a

few seconds)

- Save Project
- Save Project As âMyProject_edit.aupâ (the underscore is the critical

part) **in the same directory**

â the âMyProject_edit_dataâ folder is created and filled
â the âMyProject_edit.aupâ file is created
â the âMyProject_dataâ folder **is deleted**!!!
This is a regression on 2.1.2.
â Bill
------------------------------------------------------------

------------------

Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------

------------------

Post by James Crook
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------

------------------

Post by Steve the Fiddle
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2017-02-19 18:58:02 UTC

Yes we are keen on automated test - in principle.

* I think it finds fewer bugs than one might hope.
* Some test suites run a long time and end up testing 'the same things
over and over' because they are run so many times, which can be very
wasteful - and not a net win.
* Creating a good test suite (retrospectively) is a lot of development work.

I like tests when they do double duty. For example a script to create
all the images in the manual would give audacity a good workout and be
useful in other ways.
I like tests that are more than pass-fail. For example tests that give
performance figures give us figures to aim to beat - and help us
communicate about different hardware. Gale has some VERY slow machines
compared to what developers expect. It's good to know about that.
I like tests that are 'built-in' so that we are gathering statistics
about 'headroom' and such in running programs, and even presenting it to
users, rather than separate 'destruction testing'.

If we are starting on test automation, I would like us to start by
working out how to use scripting to create the images in the manual.

--James.

Post by Darrell Walisser
Just wondering if anyone has proposed or been thinking about adding unit
tests or other test automation to Audacity. This bug strikes me as one that
could be added to a conventional unit test.
I've done a little digging and there are tools available to test the GUI,
either by interaction record/playback tools (totally decoupled from the
source code) or writing more conventional unit tests with (hopefully) a
library that hooks into wxWidgets. There are a few possibilities listed on
wxWidgets.org.
https://wiki.wxwidgets.org/Tools#Testing
And there is Audacity's own scripting system that could be used to test
some things as well and might encourage extending it to test even more
things (if that's desired!).

Post by Steve the Fiddle
Ouch. Confirmed on Linux.
Steve

Post by Bill Wharrie
If you “Save Project As” and append “_<anything>” (that is,

underscore followed by any text) to the project name, the original project
data folder will be deleted.

Post by Bill Wharrie
- new project
- Save Project As “MyProject.aup” (for example)
- make some content (I used 30 minutes noise so the save would take a

few seconds)

Post by Bill Wharrie
- Save Project
- Save Project As “MyProject_edit.aup” (the underscore is the critical

part) **in the same directory**

Post by Bill Wharrie
— the “MyProject_edit_data” folder is created and filled
— the “MyProject_edit.aup” file is created
— the “MyProject_data” folder **is deleted**!!!
This is a regression on 2.1.2.
— Bill
------------------------------------------------------------

Bill Wharrie

2017-02-19 16:25:29 UTC

Post by James Crook
The problem is NOT the _.

Oops. Guess I should have tested more thoroughly. I’m in the habit of putting things like “_EQ” or “_Reverb” on the end of project names to identify different versions

But glad that James found it and has already fixed it.

— Bill

Peter Sampson

2017-02-19 16:29:47 UTC

Post by Bill Wharrie
But glad that James found it and has already fixed it.

+1 ;-))

but a good catch Bill.

Peter.

Cliff Scott

2017-02-20 04:27:37 UTC

I just found out how dangerous it is. I always save the original recording then save under new names at several points in the editing process. I just was looking in my projects directory found all the data files for February work for copies are gone except for the last save I did. Yikes!!! In this case it is not a big problem as I doubt I will be needing the earlier versions once the editing is done, but it could be really serious if for some reason I had to go back and change something. It does seem strange though that only this months work is affected. Why not earlier ones before February? I hope what James found as the issue will answer this. I been using the same naming convention for a long time so this seems really strange.

Cliff

Peter Sampson

2017-02-20 12:32:17 UTC