Re: [Audacity-quality] "Delete orphaned files (safe and recommended)"

[Gale A. <ga...@au...>]

| From Steve the Fiddle <ste...@gm...> 
| Thu, 4 Nov 2010 17:59:05 +0000
| Subject: [Audacity-quality] "Delete orphaned files (safe and recommended)"
> On Thu, Nov 4, 2010 at 5:35 AM, Gale Andrews <ga...@au...> wrote:
> > | From Steve the Fiddle <ste...@gm...>
> > | Wed, 3 Nov 2010 22:34:58 +0000
> > | Subject: [Audacity-quality] "Delete orphaned files (safe and recommended)"
> >> "Delete orphaned files (safe and recommended)"
> >> Under what circumstances is it safe and/or recommended?
> >> From my own experience, and from numerous posts on the forum it is
> >> profoundly unsafe and to be avoided as it destroys the last ditch hope
> >> of salvaging data from a broken project.
> >
> > Steve,
> >
> > This was (at least mostly) fixed in the course of Vaughan's work on
> > Bug 113 (Dependencies dialogue not safe against user error):
> > http://bugzilla.audacityteam.org/show_bug.cgi?id=113  
> >
> > ... Please see the comments between Vaughan and myself in Bug 113
> > for how decisions were made. As Bug 113 is still stuck on "devel-fix
> > made", I'd really welcome you and Bill giving it a good testing on
> > Linux and (especially important) Mac. I've been meaning to ask that
> > for a while. Note the bug is not about if a project has orphans, missing
> > blockfiles, missing summary files or missing aliased audio files, but
> > about how Audacity presents that data to the user to protect them
> > from needless errors.
> >
> 
> Do you have any specific tests in mind?
> If not, I'll read through that (long) bugzilla thread over the weekend
> and see what I can come up with.

In some ways it might be best to have an open mind about it to begin 
with, and then see if any concerns you have were discussed in the 
thread. Take a look at the errors in Show Log to see if you think they
are sufficiently explanatory. 

To see all four error messages, you can try opening these test projects
individually:
http://code.google.com/p/audacity/source/browse/audacity-src/trunk#trunk/tests/Project%20Check%20tests

Or create your own single messed-up project that has an imported 
aliased WAV and an imported MP3, delete the WAV, then rename
some of the .au files in the _data folder and delete some .aufs ... 

Also, root dirs still seem to have issues. If I set the Audacity temp 
dir to a root Windows directory like E:\, SVN HEAD puts the temp
data in the Audacity working directory and then leaves it there 
when closing the project. This doesn't now seem to create a practical 
problem if you save the project or crash it and recover it, but it looks
very unsafe to me - the autosave datadir is pointing to root E:\
whereas the data isn't actually there at all, so could be user deleted
and then the project is trashed.   

1.2 doesn't have this issue and saves the temp files where you specify.
Can you replicate anything like this on Mac/Linux?   


> >> "Append Import" is a highly requested feature that I hope will one day
> >> be implemented and a side effect of such a feature is that it would
> >> ease the pain of manually stitching together orphaned data files.
> >
> > Does it help in stitching together recovered .au files when they are in
> > random order? I think the naming scheme could legitimately be
> > considered as part of the work on Bug 137.
> >
> 
> The file names are in random order, but I thought  that they could be
> sorted by date, bulk renamed, then stitched together?
> or does it no longer work that way (I usually just start again from my
> last backup if the project is not automatically recovered, but not
> everyone is as obsessive about back-ups as I am).

If you are going to attempt date sort and bulk rename I think you would 
use the Crash Recovery Utility to then do the stitching together wouldn't
you?

The problem is that whether you use Crash Recovery Utility or import the
.au's in apparent order and stitch them end-to-end, the resultant track 
won't I believe be in the correct order unless what you are recovering is
a mono, unedited recording. See:
http://forum.audacityteam.org/viewtopic.php?f=17&t=38966#p101861




Gale