Some options are: 1) just add a line or two to my man page patch showing what recovery can and can't presently be done. (No need for my temporary file, use a pipe too.) 2) Also implement that step where everything is uncompressed and put into lost+found, and document that they should expect to just see a lot of connector markings, and if there are useful strings in there then they are just lucky. We did the job asked: recovered to the best extent of what they gave us. JK> So I am inclined to leave it as-is: a patch in the list archive. If and JK> when the day comes when somebody loses some super-important data and JK> somehow matches all of these criteria, then they can consult whatever JK> aged and senile git gurus still exist to pull the patch out and see if JK> anything can be recovered. I've read too many cases in RISKS Digest, news:comp.risks, about years later organizations trying to recover some weird format or media. Therefore I urge you to strike while the iron is hot and hook up the function into the code. Maybe some have never tried to recover data, but for those that one day might, they will be thanking you over and over for taking this opportunity to give them a chance. In many cases the few shreds they can recover might be all they need. Also one can see the innards of git -- no more black box. If I were creating a new binary format, I would be sure to also provide decoder tools. Otherwise it is just like it requires its own proprietary environment to reveal any of its innards. Sure, you can say well that data is mainly useless... but it is better than nothing -- we did the best with what they gave us. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
