Bugzilla – Bug 2106
Mac build for one architecture can't recover autosave files made by build for the other
Last modified: 2019-07-26 10:46:00 UTC
At James' request, I am making this a separate bug from bug 2101, which was about the corruption of the recovery file that used to happen in this case. But as I also explained in the comments at that bug, I do not think fixing this bug is worth the trouble. Auto recovery assumes that the binary recovery file was written with the same data type sizes and endianness as for the processor that is interpreting the file. Recovery file format might be augmented to include that information in a header, allowing interpretation of the saved file on a different processor. If recovery file format is not changed, then it is too much trouble to deduce the sizes and endianness. So if there is any fix, it will not recover files saved by different architectures and also by Audacity versions that predate the fix.
This means that Recovery on Mac is both backwards and forwards incompatible between 64-bit and 32-bit Audacities. This is technically a regression on 2.3.0 as for that release and earlier we only had 32-bit Mac Audacities - so this issue could not arise. Note that this is not consistent with the compatibility of Audacity projects which can be switched between 54-bit Audacities and 32-bit Audacities. I am inclined to agree with Paul (in Comment #0 ) that I, too, do not think fixing this bug is worth the trouble. I am pondering whether we should make this a P3 and Release Note it or whether we can just rely on the error message fix proposed for Bug #2101 - I am holding fire on that currently until I can get a Mac build to test with the fix for 2101.
This is a fringe case as most users when they upgrade install over their existing Audacity installation.
(In reply to Peter Sampson from comment #2) Yes, but it should be noted that the recovery files are at ~/Library/Application\ Support/audacity/SessionData which is not rewritten when reinstalling Audacity on Mac. One version's recovery file being opened by another version is not impossible.
If we used ~/Library/Application\ Support/audacity/SessionData64Bit then 64 bit and 32 bit would recover independently. We would then not have a problem in either direction.
(In reply to James Crook from comment #4) >If we used ~/Library/Application\ Support/audacity/SessionData64Bit ... But we are too late now to make this retro-fix for 2.3.1 64-bit (unless you get your TARDIS working James).
Yes, 2.3.1 would still have the bug, but it would be 'fixed' in 2.3.2.
(In reply to James Crook from comment #6) So, are we gonna fix it like this for 2.3.2 and onwards ?
(In reply to James Crook from comment #4) This suggested fix by James has not been incorporated in 2.3.2 (as tesing on Mac of 2.2.2 RC001 shows) So this is carried forward as a potential fix for 2.3.3 (or a subsequent release if 2.3.3 is purely " Paul's big sweepy refactoring" under-the-hood work).
I discussed with JAMES - WE BOTH AGREE It's an upgraders issue, AND WE don't accept the argument that enough users will run both 32 bit and 64 bit, and can be closed as WONT FIX.
