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
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 is will
not delete the actual file.
Then, later, with the current code, these will get flagged as orphans in
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
> 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()?
* 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