We could, of course, just unlock the pluginregistry.cfg file - I would prefer this approach.  

Or we may wish to have a warning or info dialog asking the user if they want their audacity.cfg to be unlocked.

Also crashes if you

1) Launch Audacity
2) lock the pluginregistry.cfg
3) Effect > Add / Remove Plug-ins...
4) Crash

Fixed minimally at

https://github.com/audacity/audacity/commit/1fa46eb0850470d1fcda5d80cfc208f480a46f19

This fix just makes a warning message.

(And strictly speaking this wasn't a crash:  the Audacity program was exiting gracefully, just giving no indication why)

I do not understand why this was distinct from bug 2134

(In reply to Paul L from comment #4)
>I do not understand why this was distinct from bug 2134

Because different config files are involved and though they may be close cousins - from a QA and user perspective they are different .

Indeed the supposed "fix" for 2134 - does not lead to this bug being fixed.

Testing on W10 with audacity-2.3.3-alpha-277-bdcb55467f725ad6e138a54da7e76244d3cc81eb

Still crashes at Step 3

Testing on macOS 10.14.5 Mojave with alpha 2.3.3 jc002 of 30Jun19

As with Windows I get an immediate crash.

I looks like a couple of temp files are created but they are immediately removed

Foolish me, I didn't read the description closely.

Now I see the crash happens here:

   // Create/Open the registry
   wxFileConfig registry(wxEmptyString, wxEmptyString, FileNames::PluginRegistry());

   // Clear it out
   registry.DeleteAll();

   // Write the version string
   registry.Write(REGVERKEY, REGVERCUR);

And I could also blame wxWidgets for a bug.  TheDeleteAll() call returns false, which our code ignores, but leaves wxFileConfig in an inconsistent state that causes Write to crash within wxWidgets.

(In reply to Paul L from comment #8)

... and if I try to make the function return after detecting that DeleteAll failed, then wxWidgets crashes anyway in the destructor of wxFileConfig!

So is this not fixable short of rebuilding our wxWidgets with some source code changes?

Demoting to P2 as this is not caused in normal usage of Audacity - possible use cases are:
a) Virus checker locks the file

b) user locks the file thinking that it protects contents from change

Demoted to P3 with a Release Note and Worraound as this file should not become locked in normal use of Audacity.

Near as I can tell, this no longer crashes.  You do get a few error dialogs, but Audacity does exit gracefully without a crash.

Testing on W10 with Audacity 3.0.0 4e6e3c2

I still get a crash, but I gad to click my shotcit icon several times - the first couple of times nothing at all happened.

Fix in:

https://github.com/audacity/audacity/commit/9e5ec6d

Testing on W10 with Audacity 3.0.0 6c44b4f

This now does not crash - but ...

Immediately on launch you get the error message
>The plugin registry file is not wtiteable:
>C:\Users\Peter\AppData\Roaming\audacity\pluginregistry.cfg
>Settings were not sabed.

Clicking the OK button Audacity proceeds to launch.

BUT observe in Windows Explorer:  that the plginregistry.cfg has not been unlocked


So marking this REOPENED for this residual

Worse Still.

After that last test I:
a) purge the entire contents of mu audacity settings folder
b) relaunch Audacity 3.0.0 6c44b4f
c) Observe: I get the error message
>The plugin registry file is not writeable:
>C:\Users\Peter\AppData\Roaming\audacity\pluginregistry.cfg
>Settings were not saved.

BUT after step a) there is no extant pluginregistry.cfg file 


If I then try to launch 2.4.2 this opens fine with no error message  
I can then open Audacity 3.0.0 6c44b4f without the error message.

(In reply to Peter Sampson from comment #16)
> Worse Still.
> 
> After that last test I:
> a) purge the entire contents of mu audacity settings folder
> b) relaunch Audacity 3.0.0 6c44b4f
> c) Observe: I get the error message
> >The plugin registry file is not writeable:
> >C:\Users\Peter\AppData\Roaming\audacity\pluginregistry.cfg
> >Settings were not saved.
> 
> BUT after step a) there is no extant pluginregistry.cfg file 
> 
> 
> If I then try to launch 2.4.2 this opens fine with no error message  
> I can then open Audacity 3.0.0 6c44b4f without the error message.

HAHAHAHA!  (and DOH!)  Didn't think about that situation.  Easy to fix.

(In reply to Peter Sampson from comment #15)
> Testing on W10 with Audacity 3.0.0 6c44b4f
> 
> This now does not crash - but ...
> 
> Immediately on launch you get the error message
> >The plugin registry file is not wtiteable:
> >C:\Users\Peter\AppData\Roaming\audacity\pluginregistry.cfg
> >Settings were not sabed.
> 
> Clicking the OK button Audacity proceeds to launch.
> 
> BUT observe in Windows Explorer:  that the plginregistry.cfg has not been
> unlocked
> 
I simply check to see if it's writable. What do you suggest we do to unlock it? If we just delete it, the user would lose their choices of plugins. We could try resetting the writable permission, but what if it's on a read only filesystem?

I figured we just let the user know and let them figure it out. Maybe we need a firmer error message and quit Audacity rather than continuing initialization?

One important thing is that the message does not have a "?" help button.  It would need a new error page in the Manual (I can do that).  Note that the error message just says "unwritable" it doesn't mention "locking" - but if we have a help button we can deal with that on the error/help page

I am unsure of the best approach - I have written a QA email thread for discussion.

1) For now I think the immediate safest thing to do is abort the launch after the user clicks the OK button in the message.

2) An improved option would be:
Change the error message so that it offers to unlock the file for the user with a YES/NO - and No would then lead to an aborted launch.

(In reply to Peter Sampson from comment #19)
>1) For now I think the immediate safest thing to do is abort the launch 
>after the user clicks the OK button in the message.

It's basically unsafe to proceed because if the user then or later tries to unable/disable/add plug-ins they will be blocked.

Fix in:

https://github.com/audacity/audacity/commit/21296b0

Seems to work fine, but I need Paul's with setting up an exception to exit Audacity a bit more gently.

(In reply to Leland Lucius from comment #21)

Tested on W10 with Audacity 3.0.0 21296b0

This now works properly on Windows, with
a) an improved message
b) help button in the message
c) no launch while the problem remains
d) fixing the problem by unlocking and then using the Retry button proceeds to launch
e) the Quit Audacity button - "does what it says on the tin"

(In reply to Leland Lucius from comment #21)

Tested on macOS 11.1 Big Sur with Audacity 3.0.0 21296b0

This now works properly on Mac, with
a) an error message
b) help button in the message
c) no launch while the problem remains
d) fixing the problem by unlocking and then using the Retry button proceeds to launch
e) the Quit Audacity button - "does what it says on the tin"

REOPENED for Residual crash on Mac

1) Finder
2) Right click on file
3) Select Get Info

In the top block "General" (you may need to expand it)there is a checkbox for locked.

This same crash also happens with a "Locked" and the unlocked pluginsettings.cfg - see Bug #2652

It does not happen with a locked and then unlocked audacity.cfg file

And yes, repeatable - every time.

This is the same problem that was causing bug #1561, though the fix for that one may have been a little heavy handed and could have been fixed the same way as this one.

This particular crash is happening because the OnInit() routine was split into two routines and the InitPart2() runs after OnInit() exits. When that happens the "Exist On Frame Delete" flag for the Mac is reset and whenever the first displayed dialog (the configuration file retry dialog in this case) is deleted, Audacity proceeds to exit.

Simple fix committed in:

https://github.com/audacity/audacity/commit/4f7affad3f73d9fed71fefa4169949a489a40b26

(In reply to Leland Lucius from comment #25)
Testing on macOS 11.1 Big Sur with Audacity 3.0.0 392360a

This Now works properly with locking via
a) the "Locked" checkbox in Finder>Get Info, or
b) setting the file "Read Only"  in Finder>Get Info


Also rechecked that this still works on W10 with this latest build - it does.