Quantcast

Audacity 2.1.3 RC1 potential data loss

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Audacity 2.1.3 RC1 potential data loss

Bill Wharrie
Summary:
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.

Steps:
- 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Audacity 2.1.3 RC1 potential data loss

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.



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.




On 2/19/2017 4:35 AM, Bill Wharrie wrote:

> Summary:
> 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.
>
> Steps:
> - 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Audacity 2.1.3 RC1 potential data loss

Stevethefiddle
Ouch. Confirmed on Linux.

Steve

On 19 February 2017 at 09:48, James Crook <[hidden email]> wrote:

> 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.
>
>
>
>
> On 2/19/2017 4:35 AM, Bill Wharrie wrote:
>> Summary:
>> 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.
>>
>> Steps:
>> - 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Audacity 2.1.3 RC1 potential data loss

Bill Wharrie
In reply to this post by James Crook

> On 2017/02/19, at 4:48 AM, James Crook <[hidden email]> wrote:
> 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
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Audacity 2.1.3 RC1 potential data loss

Peter Sampson-2
Bill wrote:
>But glad that James found it and has already fixed it.

+1  ;-))

but a good catch Bill.

Peter.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Audacity 2.1.3 RC1 potential data loss

Gale
Administrator
In reply to this post by Stevethefiddle
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


On 19 February 2017 at 14:07, Steve the Fiddle <[hidden email]> wrote:

> Ouch. Confirmed on Linux.
>
> Steve
>
> On 19 February 2017 at 09:48, James Crook <[hidden email]> wrote:
>> 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.
>>
>>
>>
>>
>> On 2/19/2017 4:35 AM, Bill Wharrie wrote:
>>> Summary:
>>> 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.
>>>
>>> Steps:
>>> - 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Audacity 2.1.3 RC1 potential data loss

James Crook
On 2/19/2017 5:13 PM, Gale Andrews wrote:
> 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.
Since that's exactly the mistake I made too, it's a very excusable
mistake :-)

> 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.

> 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.




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Audacity 2.1.3 RC1 potential data loss

Darrell Walisser
In reply to this post by Gale
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.


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!).


On Sun, Feb 19, 2017 at 12:13 PM, Gale Andrews <[hidden email]> wrote:
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


On 19 February 2017 at 14:07, Steve the Fiddle <[hidden email]> wrote:
> Ouch. Confirmed on Linux.
>
> Steve
>
> On 19 February 2017 at 09:48, James Crook <[hidden email]> wrote:
>> 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.
>>
>>
>>
>>
>> On 2/19/2017 4:35 AM, Bill Wharrie wrote:
>>> Summary:
>>> 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.
>>>
>>> Steps:
>>> - 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Audacity 2.1.3 RC1 potential data loss

James Crook
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.


On 2/19/2017 5:48 PM, Darrell Walisser wrote:

> 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!).
>
>
> On Sun, Feb 19, 2017 at 12:13 PM, Gale Andrews <[hidden email]>
> wrote:
>
>> 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
>>
>>
>> On 19 February 2017 at 14:07, Steve the Fiddle <[hidden email]>
>> wrote:
>>> Ouch. Confirmed on Linux.
>>>
>>> Steve
>>>
>>> On 19 February 2017 at 09:48, James Crook <[hidden email]> wrote:
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>> On 2/19/2017 4:35 AM, Bill Wharrie wrote:
>>>>> Summary:
>>>>> 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.
>>>>> Steps:
>>>>> - 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Audacity 2.1.3 RC1 potential data loss

Gale
Administrator
In reply to this post by James Crook
On 19 February 2017 at 17:39, James Crook <[hidden email]> wrote:

> On 2/19/2017 5:13 PM, Gale Andrews wrote:
>> 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.
> Since that's exactly the mistake I made too, it's a very excusable
> mistake :-)
>
>> 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.
>
>> 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.


> 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.


> 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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Audacity 2.1.3 RC1 potential data loss

James Crook
On 2/19/2017 7:13 PM, Gale Andrews wrote:
> On 19 February 2017 at 17:39, James Crook <[hidden email]> wrote:
>
>> 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.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Audacity 2.1.3 RC1 potential data loss

Cliff Scott
In reply to this post by James Crook

> On Feb 19, 2017, at 3:48 AM, James Crook <[hidden email]> wrote:
>
> 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.
>

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

>
>
>
> On 2/19/2017 4:35 AM, Bill Wharrie wrote:
>> Summary:
>> 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.
>>
>> Steps:
>> - 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Audacity 2.1.3 RC1 potential data loss

Peter Sampson-2
Tested this on the latest nightlies on my W10 laptop and my MAcbook Pro Sierra macOS 10.12.3.

This seems to be fixed now on both platforms.

Created a project Saved As two different versions of it.  All three sets of project folders retained
with no deletions.  And all three projects properly openable.

Peter

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...