Raised to P2.  When is failure to write a file not a problem?  It was previously only a P4, on assumption that failure to write a file was rare and due to contrived user error such as write protecting audacity.cfg or operating with an overfull file system.  However now that we know that virus checkers can prevent writing a file and other errors probably do too, this bug rises up the charts.  It is blocking two high priority bugs, #1263 and #1266

I decided to move the release note for bug 1263 into the release note for this bug. I think it is then clearer to the user that they will see the symptoms of both bugs. 

On Mac and Linux in the permissions denial case, there are no .tmp files produced, but no write to the log either. Even with that information, I think this bug (will be) closer to P3 when the mandatory fix for bug 1266 is made. Bug 437 (P2) looks more important to me at that point, though harder to fix. I added  
"Settings" to this bug title to on the grounds of distinguishing it from 
bug 437. 

I think this bug 1264 and bug 1263 should not block 1266 so I removed the block. Such a block would to me make 1264 and 1263 P1, which they are not, even if James finds it better to fix all three together. We could live in a release with residual build up of .tmp files on Windows if the .cfg files were updated, and could live with rarish permission issues on settings files.

As with Bug #1263

Demoted from P3 to P4 as we are now less gung-ho about release notes (there are too many for users to wade through)

Testing on W10 with audacity-2.3.3-alpha-271-d84ab5948d544eec6ba6a648d76d31ef9d5edc88

At step 4 there remains no report of the problem - it looks like it works as Audacity has changed (change host is an easy test on Win) - but examining the audacity.cfg file shows that the change has not been recorded.

If I exit Audacity after Step 4 - I get the error message
>Failed to update the user configuration file 

Note that it fails to warn me that that is because the file is locked readonly.

But worse when I try re relaunch Audacity it fails to launch with no warning (I shall be logging that as a separate bug probably P1)


BTW this is really two different bugs - which is why I split the steps into two distibct Use Cases

Testing on W10 with audacity-2.3.3-alpha-271-d84ab5948d544eec6ba6a648d76d31ef9d5edc88

Testing Use-case-2
At Step 8) not only is there no message to say the plugin settings can't be stored - much WORSE still is that the effect is not applied (as Gale reported in the Release Note) - not for normal effects or for RTP effects.

And yes there is a build up of temporary files plu***.tmp - and they remain after closing and relaunching Audacity, not cleaned-up, purged.  See also Bug #1263

Testing on macOS 10.14.5 with Mac alpha jc001

Use Case-1 oddly does not seem top affect Mac

But Use Case-2 fails on Mac - effects cannot be applied when pluginsettings.cfg is locked.


So failure on W10 and Mac => assume all platforms

And I think this silent unxplained failure to implement effects warrants re-raising this to P2 (as James did back in 2015)

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

Testing on macOS 10.15.5 with Audacity 2.4.0 b4d6595

This bug remains extant for 2.4.0

Testing on macOS 10.15.5 with Audacity 2.4.0 b4d6595

This bug remains extant for 2.4.0

Anything that uses the wxFileConfig class (like audacity.cfg and plug*.cfg) will have this same problem.  As mentioned in https://bugzilla.audacityteam.org/show_bug.cgi?id=1263, I can add an error dialog telling the user to look in the Audacity log for more info.  The wxFileConfig class emits messages in case of failure and they will go there.

I've just tried the "message" dialog idea and there's a slight problem with it.  We "Flush" changes to the audacity.cfg file all over the place and we'd get a message box for every single Flush.  And the majority of Flushes do not check the success or failure, so will just keep throwing up the dialog.  (Exiting preferences throws up about 10 message dialogs.)

So, I'm wondering if this might be a really good case for using Paul's fancy exception handling.  Would need help from Paul to get it right though.

We used to get user reports on the Forum with this happening - but we have not had this for a very long while now - we used to think that maybe the files got locked by virus checkers,

So the basic way of this happening is "extreme user error" i.e. the user deliberately locking the file.

Accordingly I am going to downgrade this to P4

Created attachment 1073 [details]
config file locked error

Tested on W10 with Audacity 3.0.0 6c44b4f

If audacity.cfg gets locked after audacity has successfully launched
1) changes to the audacity.cfg file (via preferences say) take place 
an example being say turning on track name as overlay.

2) It is only when the user exits from Audacity that they are made aware of this issue
a) They see the error message (see attachment)
b) they lose any changes that they made in prefs (or other things that are in audacity.cfg)


See also Bug #2649
>Launching Audacity with a locked audacity.cfg file gives not one but 
>three error messages - and no help
So on launch with a locked audacity.cfg is blocked - albeit with two additional redundant error messages and no help

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.

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"

Tested on macOS 11.1 Big Sur with Audacity 3.0.0 21296b0

On Mac there is no error message - instead the change to the prefs in Step 3 is actually made by Audacity - and examining the file info with Finder shows that Audacity (or macOS actually unlocks) the file so it can write to it.

So I think this is fine on Mac

(In reply to Peter Sampson from comment #16)
> Tested on macOS 11.1 Big Sur with Audacity 3.0.0 21296b0
> 
> On Mac there is no error message - instead the change to the prefs in Step 3
> is actually made by Audacity - and examining the file info with Finder shows
> that Audacity (or macOS actually unlocks) the file so it can write to it.
> 

This took me by surprise the first time it happened. And it will happen on Linux as well. Audacity isn't actively unlocking the file, it's just a side effect of how it writes the configuration changes.

It first renames an existing "audacity.cfg" to "audacity.cfg.bkp". Now the "read only" flag that you set is on the "audacity.cfg.bkp" file. Next, an entirely new "audacity.cfg" file is written and this one won't have the "read only" flag set, so the write succeeds. Finally, the "audacity.cfg.bkp" file is removed.