…it is fixable.
Of course, as long as there is an orphaned attachment, you are likely to receive stack traces after attaching a file to something else, but it’s an easy fix.
I had deleted a bunch of snips that were publicly visible that shouldn’t have been, and it appeared that I had missed one attachment. “Who cares?” you may ask: apparently SnipSnap does. I started seeing stack traces getting thrown (of course I fixed it before copying the actual trace) when it tried to perform the query after the upload of the new attachment – methinks there is a weird join happening, as it was an “Unable to perform query” trace if I recall correctly. The file was uploaded, but the query afterwards failed.
Anyways, you may be wondering “How can I possibly delete an attachment for a snip that is deleted? I can’t get to the snip page to click on the attachments link!”
Read ahead and you will learn, young grasshopper:
Assume your snip is named ‘I am an idiot for deleting a snip that still had an attachment’:
- enter the url (this will take you directly to the attachment page, bypassing the “snip not found” error page)
- check the box beside all of the orphaned attachments
- click ‘Delete File(s)’
Now SnipSnap should be all happy again.
It appears SnipSnap allows you to go to the attachment page for any value after the name parameter in URL – meaning you can force an orphaned attachment. This is probably a bug – if a snip is deleted, chances are all of its attachments should be as well. That way we could have the behaviour that you can’t go to the attachment page for a snip that doesn’t exist.