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

[Bill W. <bi...@go...>]

On 4-Nov-10, at 1:59 PM, Steve the Fiddle wrote:

> 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.
>>>
>> | From Steve the Fiddle <ste...@gm...>
>> | Wed, 3 Nov 2010 23:39:53 +0000
>> | Subject: [Audacity-quality] "Delete orphaned files (safe and  
>> recommended)"
>>> On Wed, Nov 3, 2010 at 11:11 PM, Bill Wharrie <bi...@go...>  
>>> wrote:
>>>> ... If the files are "orphaned" that means there is no reference  
>>>> to them
>>>> in the AUP file. The only time you wouldn't want to delete the
>>>> orphaned files is if you were prepared to manually stitch those
>>>> orphaned files back into your project - a non-trivial undertaking.
>>>> There is no way to automatically stitch the .au files of a 1.3.x
>>>> project back together the way there was for 1.2.
>>>>
>>>> -- Bill
>>>
>>> Certainly it is a non-trivial undertaking, but providing the data  
>>> has
>>> not been erased it is not impossible.
>>>
>>> On the grounds of "difficulty", the error message could say  
>>> something like:
>>> "Orphaned block files detected. If this is a result of a crash it  
>>> will
>>> be extremely difficult salvage any of this data. Delete? Yes/No"
>>> rather than saying that it is "Safe" to delete the files.
>>>
>>> The message is also used in Audacity 1.2.x where crash recovery  
>>> tools
>>> do exist, so "difficulty" is clearly not the reason for the current
>>> wording.
>>
>> 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
>>
>> See here for how the "Orphan Blockfile(s)" dialogue looks in SVN  
>> HEAD:
>> http://www.gaclrecords.org.uk/orphan_message.png
>
> Sorry, I'd missed that.
> I think that's very much better.
>
>> I would possibly argue we shouldn't say that orphans "should be  
>> deleted"
>> while we still have Bug 137 "Unreliable project re-opening with  
>> orphaned
>> and missing blockfile errors", but we aren't now saying against the  
>> radio
>> button that deletion is "safe and recommended".
>>
>> 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.
>
>>
>>> "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).

Sorting the AU files by creation date does not help put them in the  
right order if you have done any editing on the file. Since Audacity  
creates new blockfiles as needed, you end up with creation dates that  
reflect the order of editing, rather than the order of recording.

Furthermore, each AU file (at least in 1.3) has a header that contains  
non-audio information. I suspect that some of it is a graphic of the  
waveform, but I cannot find any confirmation of this. So even if you  
could "append import" all the files, you'd have to go through and  
delete the garbage at the start of each block. Try it on any AU file  
created by 1.3.x.

-- Bill