Bugzilla – Bug 1263
Build up of aud***.tmp files in Roaming->Audacity if audacity.cfg is locked read-only
Last modified: 2021-02-01 12:22:42 UTC
When using a virus checker such as MacAffee, there can be a build up of files with names like aud7071.tmp in the user->Roaming->Audacity directory where the audacity.cfg file lives. More are created every time the Audacity preferences are updated.
Added release notes, steps to reproduce and (provisional) P1.
Should we be considering adding a clean-up routine on exit from Audacity to remove the aud*.tmp files?
(In reply to Peter Sampson from comment #2) Yes! However I don't think that should impact our 2.1.2 release. It's not important enough to require a respin, provided this bug is as we think it is. We do clean-up on exit, or an equivalent, for 2.1.3.
Demoted to P2 now that bug #1266 exists. Depends on #1264 as that this happens silently is an integral part of the problem.
Removed the block on 1266 per http://bugzilla.audacityteam.org/show_bug.cgi?id=1264#c2 .
I think this should be P3, given bug 1264 is currently P3. P2 for both would also be OK with me if most people want that. I think they are both P2/P3 borderline.
Leland's fix for bug 1266 should have fixed the root cause of this. I have additionally added Leland's reduction in preference flushes: https://github.com/audacity/audacity/commit/9dd79c9f808ea1abe7dddd3bf4505b3420bd70d3 There's no need for a clean-up routine if we are not creating the extra files. So marked DEVEL-FIXMADE.
(In reply to James Crook from comment #7) testing on audacity-win-r13f1349-2.1.2-alpha-27-nov-15 on W10 shows no build-up of any aud*.tmp files.
I've seen no build of TMP files in my tests for bug 1266.
(In reply to Gale Andrews from comment #9) REOPENED. Win 10, McAfee LiveSafe has been uninstalled. Oops I did not actually test against bug 1264. On a read-only audacity.cfg there still aud*.tmp files being created (but many fewer than before) and on a read-only pluginsettings.cfg plu*.tmp files are still being created. Plugins cannot be used while pluginsettings.cfg cannot be written to. Steps to Reproduce adjusted.
Good catch. My comment #7 was inaccurate! I was too caught up in bug 1266. P3 seems right.
*** STEPS UPDATED *** Note that this requires write protection of audacity.cfg!! Demoted from P3 to P4 as we are now less gung-ho about release notes (there are too many for users to wade through)
Still happens on W10 with audacity-2.3.3-alpha-271-d84ab5948d544eec6ba6a648d76d31ef9d5edc88 having the plufinsettings file locked causes a build-up of files of the form plu***.tmp - see Bug #1264 - these files are not cleaned-up or purged by Audacity Testing on macOS 10.14.5 I also see a build of of temporary files of the form audacity****** - and these are not So assume all platforms
Elevating to P2 in line with other ***.cfg locked file issues
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
I can add an error dialog informing the user that saving the configuration file has failed and to refer to Help -> Diagnostics -> Show Log for more info. They will see messages like these: 14:38:49: Error: can't remove file 'C:\Users\Yam\AppData\Roaming\audacity\audacity.cfg' (error 5: Access is denied.) 14:38:49: Error: Failed to update user configuration file. We could check for "common" causes before flushing the configuration file, but all that gets us is more specific error messages. And there will still have to be the above "catch all" for situations we don't detect. In any case, the audacity.cfg will NOT have been updated, so the user should get told about it. And there's not really anything we can do about the "tmp" files. We could "guess" that all "audXXX.tmp" files in the same directory as audacity.cfg are bogus and failed attempts, so just delete them, but it would only be a guess and might be a bit too dangerous.
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.
RM: Too risky to fix this for 2.4.0.
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
This should be fixed in: https://github.com/audacity/audacity/commit/21296b0
Tested on W10 and macOS 11.1 Big Sur with Audacity 3.0.0 accd177 This no longer happens as Audacity is blocked when audacity.cfg is locked See Bug #2649 and Bug #1264
