Audacity silently truncates export when disk full

[Benjamin Drung-2]

Hi,

if there is insufficient disk space when exporting a project to WAV,
Audacity will simply write as much as there is space available and
report that the export was successful. The bug was filed in Ubuntu [1]
and David Henningsson developed a patch (attached) for it.

[1] https://launchpad.net/bugs/259798

--
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)

[disk-full-on-export.patch]

---

Description: No error message is given when disk gets full on PCM export
 Please also have a look at the error message on sf_close and see that it
 actually works.
Bug-Ubuntu: https://launchpad.net/bugs/259798
Forwarded: yes
Author: David Henningsson <[hidden email]>
diff -Nur -x '*.orig' -x '*~' audacity-1.3.9/src/export/ExportPCM.cpp audacity-1.3.9.new/src/export/ExportPCM.cpp
--- audacity-1.3.9/src/export/ExportPCM.cpp 2009-10-11 10:24:55.418303300 +0200
+++ audacity-1.3.9.new/src/export/ExportPCM.cpp 2009-10-11 10:28:05.589104320 +0200
@@ -529,6 +529,7 @@
                        formatStr.c_str()));
 
    while(updateResult == eProgressSuccess) {
+      sampleCount samplesWritten;
       sampleCount numSamples = mixer->Process(maxBlockLen);
 
       if (numSamples == 0)
@@ -538,11 +539,20 @@
 
       ODManager::LockLibSndFileMutex();
       if (format == int16Sample)
-         sf_writef_short(sf, (short *)mixed, numSamples);
+         samplesWritten = sf_writef_short(sf, (short *)mixed, numSamples);
       else
-         sf_writef_float(sf, (float *)mixed, numSamples);
+         samplesWritten = sf_writef_float(sf, (float *)mixed, numSamples);
       ODManager::UnlockLibSndFileMutex();
 
+      if (samplesWritten != numSamples) {
+        char buffer2[1000];
+        sf_error_str(sf, buffer2, 1000);
+        /* Tried the format %s variant (like below) but got garbage, probably it depends on
+           Audacity and/or libsndfile being compiled with unicode or not */
+        wxMessageBox(_("Error while writing file (disk full?): ") + wxString::FromAscii(buffer2));
+        break;
+      }
+
       updateResult = progress->Update(mixer->MixGetCurrentTime()-t0, t1-t0);
    }
 

---

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

| From Benjamin Drung <[hidden email]>
| Sun, 11 Oct 2009 18:38:04 +0200
| Subject: [Audacity-devel] Audacity silently truncates export when disk full
> if there is insufficient disk space when exporting a project to WAV,
> Audacity will simply write as much as there is space available and
> report that the export was successful. The bug was filed in Ubuntu [1]
> and David Henningsson developed a patch (attached) for it.
>
> [1] https://launchpad.net/bugs/259798

I've never tried this on Linux, but there is no "success" message
on Windows, unless using Export Multiple. Have you tried this
with straight export in CVS HEAD and seen a "success" message?

Note we have an item on "Release Checklist not aiming" :  

"Ensure proper saving of exported audio file when Audacity runs
  out of space and warn what was done, especially on Linux (seems
  on Windows that a clean file is saved). Consider checking free
  space before starting export."

So I think you are saying on Linux too, the file is saved properly
(can be played) but truncated due to lack of space?

I don't think the current behaviour to complete the file is that bad,
hence why it was assumed this wasn't going to be "fixed" for 2.0.

If we are going to "fix" it, I'd far rather that instead of letting what
may be a very time-consuming export start and then fail it at the
end (as the patch seems to do), Audacity actually checks the
available space first and gives an option to a) complete the
truncated file when the disk runs out of space  b) Cancel (suggest
user tries another disk). There are seven votes for a disk space
check on the Wiki "Feature Requests" page, which probably
understates the demand because others have reported this as a
"bug".

I guess this is a bit more complex with export multiple since you
would ideally have to state which file would be truncated, but
Audacity must know the space needed, and other video/audio
editors check the space first before writing.

If we went with another suggestion on "not aiming" about making
copying in of uncompressed data the default (so people who delete
the files they imported straight after importing them don't get
silenced projects), space checking becomes more important.
But, we'd then make On-Demand importing non-default which
would be a shame considering this is a very successful feature.  

I haven't even tried the patch, but I wouldn't regard it as more
than a temporary kludge-fix, even if it works. Did you test it?
Other comments?





Gale

 



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[lrn-2]

Gale Andrews wrote:

> If we are going to "fix" it, I'd far rather that instead of letting what
> may be a very time-consuming export start and then fail it at the
> end (as the patch seems to do), Audacity actually checks the
> available space first and gives an option to a) complete the
> truncated file when the disk runs out of space  b) Cancel (suggest
> user tries another disk). There are seven votes for a disk space
> check on the Wiki "Feature Requests" page, which probably
> understates the demand because others have reported this as a
> "bug".
>  

c) Once Audacity runs out of space in the middle of the process, show a
dialog to the user, saying that there is not enough space to complete
the operation and that user has to either 'cancel' it (roll back, as if
nothing happened), 'stop' it (do the same as 'cancel', or should
complete the truncated file and stop the export; or just disable 'stop'
for this case) or try again (after the user frees up some space).

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Ed Musgrove-2]

A couple of thoughts come to mind -- when does Audacity "know" how much disk
space will be required for exporting? Even if Audacity knows in advance how
much disk space is required and how much disk space is available, what is to
ensure that some other thread does not start a disk write and finish the
disk write while Audacity is in the middle of its disk write thus consuming
disk space which Audacity thought to be available?

Obviously, in a pervasively multitasking multithreaded environment, there is
no absolute assurance that a write will succeed. Audacity must deal with
this in a user-friendly manner. When a disk write fails Audacity must check
for the reason and inform the user; based on that reason, Audacity must
offer the user viable choices. In the case of a disk full error Audacity
should offer the user the chance to "cancel" the process (in the case of a
multiple export situation Audacity should inform the user of which exports
succeeded), the suggestion to free up some disk space and "continue" and the
option to "redirect" the export to a different drive.

--Ed

> -----Original Message-----
> From: LRN [mailto:[hidden email]]
> Sent: Sunday, October 11, 2009 1:24 PM
> To: [hidden email]
> Subject: Re: [Audacity-devel] Audacity silently truncates export when disk
> full
>
> Gale Andrews wrote:
> > If we are going to "fix" it, I'd far rather that instead of letting
> > what may be a very time-consuming export start and then fail it at the
> > end (as the patch seems to do), Audacity actually checks the available
> > space first and gives an option to a) complete the truncated file when
> > the disk runs out of space  b) Cancel (suggest user tries another
> > disk). There are seven votes for a disk space check on the Wiki
> > "Feature Requests" page, which probably understates the demand
> because
> > others have reported this as a "bug".
> >
>
> c) Once Audacity runs out of space in the middle of the process, show a
> dialog to the user, saying that there is not enough space to complete the
> operation and that user has to either 'cancel' it (roll back, as if

nothing
> happened), 'stop' it (do the same as 'cancel', or should complete the
> truncated file and stop the export; or just disable 'stop'
> for this case) or try again (after the user frees up some space).
>
>
----------------------------------------------------------------------------
--
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
the
> only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

| From "Ed Musgrove" <[hidden email]>
| Sun, 11 Oct 2009 18:53:18 -0700
| Subject: [Audacity-devel] Audacity silently truncates export when disk full

> A couple of thoughts come to mind -- when does Audacity "know" how much disk
> space will be required for exporting? Even if Audacity knows in advance how
> much disk space is required and how much disk space is available, what is to
> ensure that some other thread does not start a disk write and finish the
> disk write while Audacity is in the middle of its disk write thus consuming
> disk space which Audacity thought to be available?
>
> Obviously, in a pervasively multitasking multithreaded environment, there is
> no absolute assurance that a write will succeed. Audacity must deal with
> this in a user-friendly manner. When a disk write fails Audacity must check
> for the reason and inform the user; based on that reason, Audacity must
> offer the user viable choices. In the case of a disk full error Audacity
> should offer the user the chance to "cancel" the process (in the case of a
> multiple export situation Audacity should inform the user of which exports
> succeeded), the suggestion to free up some disk space and "continue" and the
> option to "redirect" the export to a different drive.

Yes, fair points  - there could still be cases where a write fails
after a space check. But if it was for reasons other than disk
space (say a hardware failure while saving), Audacity wouldn't
be completing a truncated file anyway. Doesn't it already have
an appropriate message in that case?

I think the point remains that 95% of the user aggravation from
this issue would be avoided if there was a check of the disk
space available *before* exporting.  While some people might
prefer an error when space runs out to silently completing a
truncated file, IMO it really only begs the question why space
was not checked in the first place.




Gale

 

> > -----Original Message-----
> > From: LRN [mailto:[hidden email]]
> > Sent: Sunday, October 11, 2009 1:24 PM
> > To: [hidden email]
> > Subject: Re: [Audacity-devel] Audacity silently truncates export when disk
> > full
> >
> > Gale Andrews wrote:
> > > If we are going to "fix" it, I'd far rather that instead of letting
> > > what may be a very time-consuming export start and then fail it at the
> > > end (as the patch seems to do), Audacity actually checks the available
> > > space first and gives an option to a) complete the truncated file when
> > > the disk runs out of space  b) Cancel (suggest user tries another
> > > disk). There are seven votes for a disk space check on the Wiki
> > > "Feature Requests" page, which probably understates the demand
> > because
> > > others have reported this as a "bug".
> > >
> >
> > c) Once Audacity runs out of space in the middle of the process, show a
> > dialog to the user, saying that there is not enough space to complete the
> > operation and that user has to either 'cancel' it (roll back, as if
> nothing
> > happened), 'stop' it (do the same as 'cancel', or should complete the
> > truncated file and stop the export; or just disable 'stop'
> > for this case) or try again (after the user frees up some space).

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Ed Musgrove-2]

Hi Gale!

> -----Original Message-----
> From: Gale Andrews [mailto:[hidden email]]
>
> | From "Ed Musgrove" <[hidden email]> Sun, 11 Oct 2009
> | 18:53:18 -0700
> | Subject: [Audacity-devel] Audacity silently truncates export when disk
> | full
> > A couple of thoughts come to mind -- when does Audacity "know" how
> > much disk space will be required for exporting?
[Ed:] [...]
> >
> > Obviously, in a pervasively multitasking multithreaded environment,
> > there is no absolute assurance that a write will succeed.
[Ed:] [...]
>
> Yes, fair points  - there could still be cases where a write fails after a
space
> check. But if it was for reasons other than disk space (say a hardware
failure
> while saving), Audacity wouldn't be completing a truncated file anyway.
> Doesn't it already have an appropriate message in that case?
>
> I think the point remains that 95% of the user aggravation from this issue
> would be avoided if there was a check of the disk space available *before*
> exporting.  While some people might prefer an error when space runs out to
> silently completing a truncated file, IMO it really only begs the question
why
> space was not checked in the first place.

When Audacity is exporting, does it do all of its transformational
calculations in advance, writing everything to a buffer, then streaming the
buffer to a file, or does it write to the file as it calculates -- a little
bit at a time? Regardless, there is no way for Audacity to know in advance
if there will be sufficient disk space to complete the write. This is most
especially notable when the file is large. If Audacity writes everything
into a buffer in RAM before writing to disk it is easy to determine the
amount of disk space required for the file write. On the other hand, if it
writes directly to the file as it calculates it would have to calculate
(estimate) the necessary disk space. Given that a 90 minute AAC file
requires about 100,000 KB of disk space, which is a fairly small portion of
even a 100 GB hard drive, I would suspect that those users who are truly
running out of disk space (say, less than 200,000 KB) could just get a
generic warning before any export process is started.

--Ed



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel