Bug:Deleting When Open

If user deletes aliased files while project is open, playing any track in the project causes a freeze. Details | Edit

Summary Points

---

• Bug goes back to at least 1.3.8.
• Purported fix OK on Ubuntu but did not fix on Mac PPC nor Win XP.
• Proposal that we switch to default is 'copy audio'. However that disables on-demand loading.
• Users may also delete audio we depend on after closing Audacity. That's a problem too.
• Suggestion to write a Proposal User-safe Aliasfiles page, since there are more issues in this bug than the headline issue.

---

• GA: The regression is that 1.2.6 handles this gracefully, just playing the deleted track silently. This could I suppose be P3 on the grounds of user error, but my vote is P2 (a drive holding the aliased file could become unavailable). Is the short term fix an error (can't play track n)?
• MJS 2ndJan2010: This has been fixed, we are back to the 1.2.6 behaviour described above.
  • GA: 04Jan10 Works for me in Ubuntu but in Windows Unicode Release I still get freeze if I drag WAV in, SHIFT + Delete the WAV, then play. If the Unicode Release you built works properly, then I'll have to do a fresh checkout - I already built into an empty folder.
  • MJS 12thJan2010: What does "SHIFT + Delete the WAV" mean? Some sort of 'special' delete?
  • BW: 11Jan10 Still freezes on Mac PPC 10.5.8.
  • GA: 12Jan10 SHIFT + Delete on Windows and Linux permanently deletes a file, bypassing the Recycle Bin/Trash. It doesn't matter though, as delete to Recycle Bin also freezes Audacity. I've now built Unicode Debug on Win, and done a fresh checkout and built Unicode Release on Win, and in both the freeze is 100% replicable. Are you running from within VS? There most be some reason...
• GA: Note that users delete files after import very frequently, and Dependencies dialogue does nothing for that case. In fact, if you delete the file after import and Check Dependencies, then copy in the audio, this process and saving and exiting the project go without error until you open the empty project next time. Clearly Dependencies dialogue needs a file existence check after 2.0, and my view is it also needs a "don't show again" warning if user does not copy in data on exit. Some sort of warning is also needed IMO at least on first import of an aliased WAV/AIFF.
• MJS 2ndJan2010: This is the same code that "handles this gracefully" above. In this case it isn't very graceful though!
• BW 12Jan10: Just confirmed that this bug goes back to at least 1.3.8. Also agree with GA's comments above, except that I would hope that it is fixed before 2.0 (as it should if this remains a P2). In my mind this is another argument for having the "safer" option the default in Import/Export Preferences.
• GA 12Jan10:
  • Although I attached those comments to this bug as an example, I think that handling aliased files so that users don't lose their data is (mostly) a separate issue to this, and (mostly) lower priority (wordings and behavioural changes).I see it as separate from the more general Proposal Menu Reorganisation. So I'll probably start Proposal User-safe Aliasfiles unless it's thought a bad idea. One thing I want to do is reduce the verbosity of the Dependencies dialogue which I've been told can leave users not knowing what to do. However as I've said before I'd be reluctant to have "copy in" as default, otherwise many users won't be able to use on-demand.
  • As for "file-existence check for Dependencies dialogue" as P2, I'm a bit torn. It isn't a crash or freeze, but it does also apply if you delete the file after import and then exit and "copy in all data",a more likely scenario than using Check Dependencies directly. A warning "may" give some users time to recover the file if it's in the Recycle Bin. I think I will make it a separate P2, but will wait a few days for any other comments.