Shrinkfile would have failed, the log header was corrupt. No amount of shrinking would help here, the problem was not that the log was too large, it was that the log was corrupt.
OK - my mistake - as as I said a question not a solution as such. 🙂
Do you like your database consistent and durable or corrupt with missing data? If the latter, sure, they're of little practical use. The point of the log is to ensure durability of transactions and consistency of data no matter what. The backing up of the log for point-in-time recovery is a secondary usage.
Given simple recovery, what can one actually do with the log file?
p.s. this issue is 8 months old and very likely resolved one way or another by now.
OK but people are still discussing it now and I got a link to it in my daily SQLServerCentral e-mail and the topic interested me. I'm here to learn as much as anything else so thought I'd ask a question.