Re: [Audacity-devel] bug 451 and Re: identical wxLogError strings makes support more difficult

[Vaughan J. <va...@au...>]

Moving this back to bug 451... but duplicating, for completeness.

On 10/10/2011 2:25 PM, Vaughan Johnson wrote:
> On 10/10/2011 1:08 PM, Vaughan Johnson wrote:
>> [...]
>>
>> But we indeed have bigger fish to fry... More to follow.
>>
> 
> I think I've found the actual problem in bug 451, i.e., where it deletes
> the files.
> 
> In DirManager::HandleXMLTag(), it builds the various types of blockfile
> instances, in this case (bug 451 sample project), a SimpleBlockFile.
> This is done ignoring whether the XML for the blockfile has a "len"
> attribute that's bigger than mMaxSamples.
> 
> Then, for all blockfile types, it checks against mMaxSamples, and if the
> blockfile's GetLenght() is bigger, it deletes the blockfile, which in
> the BlockFile destructor, deletes the file.
> 
> I think the correct fix for this is to call Lock on the over-long
> blockfile before deleting it, so that the BlockFile destructor will
> not delete the actual file.

Did this, commit r11277.



> 
> Then, later, with the current code, these will get flagged as orphans in
> DirManager::ProjectFSCK(), but...
> 
> 
> 
> On 10/9/2011 11:55 PM, Vaughan Johnson wrote:
>> [...]
>>
>>
>> More important than their poor specificity (although they're very much
>> at the same level of checking, as they're in only one method), I'm
>> finding that at higher level, these all need to be handled
>> differently.
>> mErrorOpening has been treated as sometimes important, sometimes
>> insignificant, sometimes hacked to handle, and mostly ignored... And
>> it's totally outside the DirManager checks of orphans, etc. So
>> obviously, the original developers of this code did not completely
>> handle these errors, or integrate with DirManager checking.
>>
> 
> I've looked further into this, and indeed, in
> AudacityProject::OpenFile(), when it runs into an error in parsing a
> track (which really means Sequence set its mErrorOpening true), it goes
> ahead and creates the project, but tells DirManager::ProjectFSCK() to
> force an error. It does all the other checks, correctly finds that
> "crash sound.wav" aliased file is missing, then does the Warning that
> "Project check found file inconsistencies...".
> 
> So the higher level things to me here are:
> 
> * Why use bForceError to DirManager::ProjectFSCK() (with generic
> warning), rather than fully failing when a clip doesn't load correctly?
> That is, shouldn't we put up an error dialog (hopefully describing
> exactly the problem), and bail from AudacityProject::OpenFile() before
> the call to Initialize()?

This still needs attention. Comments?


> 
> * Alternatively, we could ask the user what to do with the files, as in
> the "Warning - Missing Aliased Files(s)" and other two dialogs in
> DirManager::ProjectFSCK().
> 
> 
> Comments?
> 

Please...

- V