BUG 2.1.2 - Cancelling File > export does not delete file


  1. Open audio
  2. File > Export Audio (e.g. MP3)
  3. Press [CANCEL] button

The audio file is left around (incomplete) after pressing CANCEL. It needs to be manually removed. If you forgot, you and up pile of files that are not complete.


In case of unfinished export, delete file


Audacity version: 2.1.2
OS: Windows 7 Premium

libsoxr (Sample rate conversion) Enabled
PortAudio (Audio playback and recording) v19
wxWidgets (Cross-platform GUI library) 3.0.2

Build Information
Program build date: Jan 9 2016
Commit Id: 53b8fd5 of Fri Jan 8 22:05:48 2016 +0000
Build type: Release build
Settings folder: C:\Users\user\AppData\Roaming\Audacity

I agree that it is confusing in that “Stop” and “Cancel” appear to do the same thing, whereas one would expect that “Cancel” to do something different (“Stop” does what I expect).
Making Audacity actually “cancel” an export is more tricky than might at first appear…

Let’s say that you chose a file name and location of an existing audio file.
Audacity warns you and asks if you want to replace the file.
If you click “Yes”, then the exporter begins overwriting the file (in accordance with your instruction).
If you now “Cancel” the export, what should happen? You have destroyed the original file by telling the exporter to overwrite it, so there is no way to completely “undo” the operation.

Perhaps Audacity should have made a back-up of the old audio file before exporting and:

  • If the export is successful, delete the backup.
  • If the export is cancelled or fails, restore the backup.
    but what should happen if the export fails because there is insufficient disk space for both the exported file and the backup?

A “pile” sounds like a bit of an exaggeration :wink:
How often do you start exporting and then change your mind? If it’s more than “very rarely” then the real problem is not really a programming issue.


For the normal behavior (no previous file to overwrite), Audacity should delete the file if export is cancelled. It’s the logical step user expects to happen. Certainly not having half written file on disk.

Typical case for the CANCEL is when one notices half way that the specified file name or location of directory is incorrect. That happens to me often enough.


if there is already a file, I don’t think it needs to be handled by default any differently. If one confirms overwrite, one gives permission to destroy the file in any case. CANCEL can therefore delete the file because it’d be unusable for playback in any case.


After adjusting the CANCEL, In next release, if time permits, there could be a User Preference to control behavior

[x] On file overwrite, use backup and restore in case of calcel

Testing the current 2.2.0 alpha development code, the case of overwriting an existing file is already handled quite well. “Cancel” does cancel the operation and the file that was being overwritten is restored. This is arguably the more important case as it’s worse to ‘accidentally’ lose data than to ‘accidentally’ retain data.

When not overwriting, “Cancel” behaves the same as “Stop”. I don’t know, but this may be an intentional design decision based on the same idea that it’s worse to ‘accidentally’ lose data than to ‘accidentally’ retain data. Personally I agree that “Cancel” should cancel. The developers don’t read this forum, so I’ll ask about this on the mailing list and report back here if I get clarification.