{"thread":{"id":"6820","subject":"Error converting from 1.4.4.1 to 1.5.0?","startedAt":"2007-02-14T16:12:44Z","lastAt":"2007-02-15T14:30:36Z","messageCount":39,"participants":["Bill Lear","Junio C Hamano","Linus Torvalds","Nicolas Pitre","Johannes Schindelin","Jakub Narebski","Simon 'corecode' Schubert","Olivier Galibert","Shawn O. Pearce","Uwe Kleine-König","Andy Parkins","Michael K. Edwards","Mark Wooding"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"34544","messageId":"17875.13564.622087.63653@lisa.zopyra.com","threadId":"6820","inReplyTo":null,"subject":"Error converting from 1.4.4.1 to 1.5.0?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-14T16:12:44Z","receivedAt":"2007-02-14T16:12:44Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"I have a 1.4.4.1 repository, non-bare, cloned from my public\nrepository. I just installed and am using the new 1.5.0 git.\n\nOn my master branch, I cleaned out some cvs ids in our text files and\ndid a git diff --- all was well.\n\nI then did a commit, and something went wrong:\n\n% git commit -a -m \"Nuke CVS Id strings\"\nerror: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5\nerror: unable to read tree object HEAD\n# On branch master\nerror: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5\nerror: unable to read tree object HEAD\n# Untracked files:\n# (use \"git add ...\" to include in what will be committed)\n#\n# src/ledef/\nnothing added to commit but untracked files present (use \"git add\" to track)\n\nThe \"Untracked files:\" part is fine, but what's up with the other\nerrors?\n\nI now do a git status and it shows all of my files that I changed\nas still modified, and git diff seems to show the same output.\n\n\nBill\n"},{"id":"34569","messageId":"17875.16823.981920.183618@lisa.zopyra.com","threadId":"6820","inReplyTo":"17875.13564.622087.63653@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-14T17:07:03Z","receivedAt":"2007-02-14T17:07:03Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, February 14, 2007 at 10:12:44 (-0600) Bill Lear writes:\n>I have a 1.4.4.1 repository, non-bare, cloned from my public\n>repository. I just installed and am using the new 1.5.0 git.\n>\n>On my master branch, I cleaned out some cvs ids in our text files and\n>did a git diff --- all was well.\n>\n>I then did a commit, and something went wrong:\n>\n>% git commit -a -m \"Nuke CVS Id strings\"\n>error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5\n>error: unable to read tree object HEAD\n># On branch master\n>error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5\n>error: unable to read tree object HEAD\n>...\n\nI also notice this:\n\n% git diff src/fus/testsuite/fus.design/prep4_5.s\nfatal: failed to find delta-pack base object 1e742ba82e01f5bb39ed62e6863712fd3c9b0616\ndiff --git a/src/fus/testsuite/fus.design/prep4_5.s b/src/fus/tes[...]\nindex 106a233..4e6dbd5 100644\n\nBut running diff again seems to make the warning go away, but no\nchanges are listed...bad.\n\n\nBill\n"},{"id":"34573","messageId":"7vhctor78j.fsf@assigned-by-dhcp.cox.net","threadId":"6820","inReplyTo":"17875.13564.622087.63653@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-14T17:15:08Z","receivedAt":"2007-02-14T17:15:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bill Lear writes:\n\n> I then did a commit, and something went wrong:\n>\n> % git commit -a -m \"Nuke CVS Id strings\"\n> error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5\n> error: unable to read tree object HEAD\n> # On branch master\n> error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5\n> error: unable to read tree object HEAD\n\nDoes 1.4.4 find that object? What's in HEAD (cat .git/HEAD)?\nWhat does \"git fsck-objects --full\" report?\n"},{"id":"34576","messageId":"17875.17647.74882.218627@lisa.zopyra.com","threadId":"6820","inReplyTo":"7vhctor78j.fsf@assigned-by-dhcp.cox.net","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-14T17:20:47Z","receivedAt":"2007-02-14T17:20:47Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, February 14, 2007 at 09:15:08 (-0800) Junio C Hamano writes:\n>Bill Lear writes:\n>\n>> I then did a commit, and something went wrong:\n>>\n>> % git commit -a -m \"Nuke CVS Id strings\"\n>> error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5\n>> error: unable to read tree object HEAD\n>> # On branch master\n>> error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5\n>> error: unable to read tree object HEAD\n>\n>Does 1.4.4 find that object? What's in HEAD (cat .git/HEAD)?\n>What does \"git fsck-objects --full\" report?\n\n% cat .git/HEAD\nref: refs/heads/master\n\n% git --version\ngit version 1.5.0-dirty\n\n% git fsck-objects --full\nerror: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself\nfatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27\n\n% /usr/bin/git --version\ngit version 1.4.4.1\n\n% /usr/bin/git fsck-objects --full\nerror: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself\nfatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27\n\nSo, all I did was try to do a commit with the new git ... haven't\nrecloned, or pulled from upstream...\n\n\n\nBill\n"},{"id":"34582","messageId":"7vy7n0pr9x.fsf@assigned-by-dhcp.cox.net","threadId":"6820","inReplyTo":"17875.17647.74882.218627@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-14T17:45:14Z","receivedAt":"2007-02-14T17:45:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bill Lear writes:\n\n> % git fsck-objects --full\n> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself\n> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27\n>\n>\n> % /usr/bin/git --version\n> git version 1.4.4.1\n>\n> % /usr/bin/git fsck-objects --full\n> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself\n> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27\n>\n> So, all I did was try to do a commit with the new git ... haven't\n> recloned, or pulled from upstream...\n\nIf you haven't packed the repository lately, the above indicates\nthis is not an issue between 1.4.4.1 and 1.5.0, but you had a\ncorrupt packfile before even started.\n\nHow big is this pack, what platform are you working on and whose\nSHA-1 implementation do you use?\n\nWe used to have a bug that fed really large buffer to\nSHA1_Update() function of the underlying SHA-1 library,\nwhich was discovered exactly because somebody reported that\n\"mismatch with itself\" message.\n\nAlso, do you have a huge blob in the repository? I do not know\nif it is related but the write_sha1_file_prepare() function on\nthe codepath to write loose objects out would trigger the same\nbug...\n"},{"id":"34600","messageId":"Pine.LNX.4.64.0702140958440.3604@woody.linux-foundation.org","threadId":"6820","inReplyTo":"17875.17647.74882.218627@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-14T18:19:53Z","receivedAt":"2007-02-14T18:19:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Feb 2007, Bill Lear wrote:\n>\n> % git fsck-objects --full\n> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself\n\nThis in itself could have been due to a historical buglet that shouldn't \nmatter (SHA1 on pack-files got miscomputed). However, that's probably NOT \nthe problem, since:\n\n> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27\n\nimplies that the pack really is corrupt.\n\nEven a single-bit error will corrupt a pack in bad ways, which is one \nreason why we're so careful with it and add its own SHA1 to the end.\n\nThe best way to proceed:\n\n - MAKE A BACKUP (\"tar\" up everything). If for no other reason than\n\n (a) then you don't have to worry about making things worse even by \n mistake\n (b) it might be interesting for others (if you can make those \n pack-files available) to try to figure out what exactly the \n corruption was. We've done it before, when it turned out to be a \n single-bit error.\n\n - if you have other git archives or just back-ups of everything, just use \n them, and throw the corrupt one away entirely (but see above on why \n it's nice to have an archive of the corruption for posterity anyway)\n\n - if you don't, you can try \"git unpack-objects -r\". See the man-page on \n why you need to first _move_ the pack-file away:\n\n\tmv .git/bad-pack.pack\n\tmv .git/bad-index.index\n\n\tgit unpack-objects -r < .git/bad-pack.pack\n\n this will unpack as many objects into loose format as it can. Hopefully \n you haven't lost much.\n\n - after that, the ones that you *did* lose, you can hopefully find in \n older git repos: even if you didn't have the *full* new repo anywhere \n else, other git repositories may have the particular objects that got \n corrupted. \"git fsck\" will tell you what is missing, and you can just \n point your .git/info/alternates file at other repositories to \"steal\" \n objects from automatically.\n\n - if you aren't missing any objects after that, you can now repack the \n repository, and then remove the alternates file:\n\n\tgit repack -a -d\n\trm .git/info/alternates\n\n because the repack will steal all the objects you need, and thus you \n don't need alternates any more.\n\nFinally: it would be very interesting to hear if you do something strange \nor unusual that could have made your chances of getting corruption higher.\n\nHave you ever seen random SIGSEV's or strange oopses, which could be a \nsign of memory corruption on your machine? Do you do a lot of things over \nNFS? (which really can corrupt things, especially in circumstances with \ndodgy ethernet chips: the UDP checksums are very weak, and some ethernet \ncards do not do a good job of checking the ethernet CRC's!).\n\n> So, all I did was try to do a commit with the new git ... haven't\n> recloned, or pulled from upstream...\n\nYes, don't do anything more (certainly do *not* repack or anything) until \nyou have tarred up and saved the current state, and then only _after_ you \nhave a good safe archive to restart from, try to fix it up.\n\nAnd if you can make the git history available to outsiders, I'd love to \nsee the corrupt tar-file (it doesn't have to be *public*, if you just can \ntrust me and perhaps a few other people with the data).\n\nSo far, as far as I can recall, we've certainly had people screw up their \nown trees by mistake, but apart from that kind of \"user error\" things, the \nonly real corruption I recall was the single-bit error in a pack-file. We \nwere able to recover that, but in general, for safety, the best way to \nprotect your data is to replicate it across multiple independent machines \n(something that git is _good_ at, happily).\n\n\t\tLinus\n"},{"id":"34604","messageId":"Pine.LNX.4.64.0702141033400.3604@woody.linux-foundation.org","threadId":"6820","inReplyTo":"Pine.LNX.4.64.0702140958440.3604@woody.linux-foundation.org","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-14T18:42:15Z","receivedAt":"2007-02-14T18:42:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Feb 2007, Linus Torvalds wrote:\n> \n> And if you can make the git history available to outsiders, I'd love to \n> see the corrupt tar-file (it doesn't have to be *public*, if you just can \n> trust me and perhaps a few other people with the data).\n\nSide note: one reason why this is nice - even if you don't care about the \ncorruption and can fix it other ways - is that the last time we had the \none-bit corruption is also the reason why we now have the \"-r\" option to \ngit-unpack-objects.\n\nIn other words, real-life corruption is not just a really nasty event, \nit's also a good way for *us* to verify that our recovery tools do as good \na job as they possibly can. Maybe there are other things like that \"-r\" \noption where we could possibly do even better.\n\nThe git data structures are designed to be extremely robust, but there's \nnothing they can do about \"corruption after the fact\". The same way that a \nlogging filesystem doesn't help if the disk itself starts getting read \nerrors, the git data structures aren't going to guarantee that you can't \nlose data if you have actual disk or memory corruption going on. \n\nThe things git can do is:\n\n - detection. The SHA1's should basically guarantee that you will never \n ever have an _undetectable_ corruption anywhere (which is really really \n easy with just about any other SCM)\n\n - make replication easy (so that once you've detected corruption, you \n have mirrors you can trust).\n\n - and finally: in the absense of replication, we can do our damndest to \n try to figure out what the data was. But in many ways, the fact that we \n are really really good at compressing data (people do love their small \n repositories) also means that we have basically no redundancy anywhere, \n because redundancy is what compression gets rid of (both delta- and \n zlib compression do it - it's very fundamentally what any compression \n is based on)\n\nbut it's always interesting to have real-life corruption cases to verify.\n\n\t\t\tLinus\n"},{"id":"34623","messageId":"17875.30187.289679.417079@lisa.zopyra.com","threadId":"6820","inReplyTo":"7vy7n0pr9x.fsf@assigned-by-dhcp.cox.net","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-14T20:49:47Z","receivedAt":"2007-02-14T20:49:47Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, February 14, 2007 at 09:45:14 (-0800) Junio C Hamano writes:\n>Bill Lear writes:\n>\n>> % git fsck-objects --full\n>> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself\n>> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27\n>>\n>>\n>> % /usr/bin/git --version\n>> git version 1.4.4.1\n>>\n>> % /usr/bin/git fsck-objects --full\n>> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself\n>> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27\n>>\n>> So, all I did was try to do a commit with the new git ... haven't\n>> recloned, or pulled from upstream...\n>\n>If you haven't packed the repository lately, the above indicates\n>this is not an issue between 1.4.4.1 and 1.5.0, but you had a\n>corrupt packfile before even started.\n>\n>How big is this pack, what platform are you working on and whose\n>SHA-1 implementation do you use?\n\nIn order:\n\n% cd .git/objects/pack\n% ls -l\n-r--r--r-- 1 rael software 77360 Feb 13 10:18 pack-23d1a9af78b4b78d...\n-r--r--r-- 1 rael software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d...\n\n[output of ls trimmed to width]\n\n% uname -a\nLinux lisa.zopyra.com 2.6.9-34.0.2.ELsmp #1 SMP Fri Jul 7 18:22:55 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux\n\nI don't know which SHA-1 implementation I use --- I just installed git\nand off I went. I do see this:\n\n% which sha1sum\n/usr/bin/sha1sum\n% sha1sum --version\nshasum (coreutils) 5.2.1\nWritten by Ulrich Drepper and Scott Miller.\n[...]\n\nBut I'm not sure which library is in use --- how do I know?\n\n>Also, do you have a huge blob in the repository? I do not know\n>if it is related but the write_sha1_file_prepare() function on\n>the codepath to write loose objects out would trigger the same\n>bug...\n\nI don't know what \"huge\" is, but the pack file seems to be the largest\nand then one of the objects is listed at 28,604,986 bytes, but nothing\nelse is very large.\n\nSo, before I get to Linus's message, I did try doing this:\n\n1) with 1.4.4.1 git, clone my public repo\n2) in this new clone, make modifications to my files as before\n3) with 1.5.0 git, do a commit\n\nand I got the same blowup on commit, and this on fsck, with 1.5.0 git:\n\n% git fsck-objects --full\nerror: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself\nerror: 00078437c23cbc04da52233f4f412219f88b8927: object corrupt or missing\nfatal: unknown object type 5 in .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n\nand with 1.4.4.1 git:\n\n% /usr/bin/git fsck-objects --full\nerror: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself\nfatal: corrupted pack file .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n\nSo (hopefully this is helpful) I look in my public repo for this pack\nfile:\n\n% ls -l /repos/git/fus/objects/pack\ntotal 88420\n-r--r--r-- 1 blear software 10376 Feb 14 10:06 pack-1a201381fe465cbf4d771aec681aff6e12648ea0.idx\n-r--r--r-- 1 blear software 753437 Feb 14 10:06 pack-1a201381fe465cbf4d771aec681aff6e12648ea0.pack\n-r--r--r-- 1 blear software 77360 Feb 13 10:57 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx\n-r--r--r-- 1 blear software 89576130 Feb 13 10:57 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n\nand notice, it is different than the same pack on my just-cloned repo\n(that is, the second clone, that I used to reproduce the first\nfailure):\n\n% ls -l objects/pack/\ntotal 87632\n-r--r--r-- 1 blear software 77360 Feb 14 12:50 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx\n-r--r--r-- 1 blear software 89548154 Feb 14 12:52 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n\nand in my first-cloned repo:\n\n% ls -l objects/pack/\ntotal 85992\n-r--r--r-- 1 blear software 77360 Feb 13 10:18 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx\n-r--r--r-- 1 blear software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n\nThe .pack files have the same SHA, but different sizes (don't know\nwhat that means).\n\nI will continue digging and on to Linus's post...\n\n\nBill\n"},{"id":"34624","messageId":"17875.30687.661794.512124@lisa.zopyra.com","threadId":"6820","inReplyTo":"17875.30187.289679.417079@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-14T20:58:07Z","receivedAt":"2007-02-14T20:58:07Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"I forgot to mention that fsck in my original public repo looks fine:\n\n% cd /repos/git/fus\n\n[with 1.4.4.1]\n% GIT_DIR=. /usr/bin/git fsck-objects --full\ndangling commit 828c0a0649d2d6b43ed13853bba33f7764f034fa\n\n[with 1.5.0]\n% GIT_DIR=. git fsck-objects --full\ndangling commit 828c0a0649d2d6b43ed13853bba33f7764f034fa\n\n\nBill\n"},{"id":"34627","messageId":"7vmz3gmojt.fsf@assigned-by-dhcp.cox.net","threadId":"6820","inReplyTo":"17875.30187.289679.417079@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-14T21:12:22Z","receivedAt":"2007-02-14T21:12:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bill Lear writes:\n\n>>How big is this pack, what platform are you working on and whose\n>>SHA-1 implementation do you use?\n>\n> In order:\n>\n> % cd .git/objects/pack\n> % ls -l\n> -r--r--r-- 1 rael software 77360 Feb 13 10:18 pack-23d1a9af78b4b78d...\n> -r--r--r-- 1 rael software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d...\n>\n> [output of ls trimmed to width]\n>\n> % uname -a\n> Linux lisa.zopyra.com 2.6.9-34.0.2.ELsmp #1 SMP Fri Jul 7 18:22:55 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux\n>\n> I don't know which SHA-1 implementation I use --- I just installed git\n> and off I went. I do see this:\n>\n> % which sha1sum\n> /usr/bin/sha1sum\n> % sha1sum --version\n> shasum (coreutils) 5.2.1\n> Written by Ulrich Drepper and Scott Miller.\n> [...]\n>\n> But I'm not sure which library is in use --- how do I know?\n\n\"ldd ~/git-master/bin/git\" tells me that it links with libcrypto.so,\nso I am using OpenSSL's SHA-1 implementation. I do not know\nwhat your distro uses (or you hand built git yourself?).\n\nI asked this question, because... \n\n>>Also, do you have a huge blob in the repository? I do not know\n>>if it is related but the write_sha1_file_prepare() function on\n>>the codepath to write loose objects out would trigger the same\n>>bug...\n>\n> I don't know what \"huge\" is, but the pack file seems to be the largest\n> and then one of the objects is listed at 28,604,986 bytes, but nothing\n> else is very large.\n\n... we had a problem that some SHA-1 implementation gave bogus\nresults when we did this:\n\n\tSHA_CTX ctx;\n\tunsigned char sha1[20];\n \n\tSHA1_Init(&ctx);\n /* hash len bytes starting from buf */\n\tSHA1_Update(&ctx, buf, len);\n\tSHA1_Final(sha1, &ctx);\n\nand asked to hash a large buffer in one go. One of the SHA1\nimplementations we ship ourselves (I think it was handcrafted\nPPC one) used to have problems. But I do not think 27MB is\nlarge enough to trigger such a library bug (the bug was integer\nwraparound of a bit counter, I think).\n\nSo it looks more and more like a bit decay as Linus suspected...\n"},{"id":"34629","messageId":"17875.31600.643352.808533@lisa.zopyra.com","threadId":"6820","inReplyTo":"Pine.LNX.4.64.0702140958440.3604@woody.linux-foundation.org","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-14T21:13:20Z","receivedAt":"2007-02-14T21:13:20Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, February 14, 2007 at 10:19:53 (-0800) Linus Torvalds writes:\n>On Wed, 14 Feb 2007, Bill Lear wrote:\n>> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27\n>\n>implies that the pack really is corrupt.\n>...\n> (b) it might be interesting for others (if you can make those \n> pack-files available) to try to figure out what exactly the \n> corruption was. We've done it before, when it turned out to be a \n> single-bit error.\n\nIf you could tell me who I should contact about this, I will.\n\n> - if you have other git archives or just back-ups of everything, just use \n> them, and throw the corrupt one away entirely (but see above on why \n> it's nice to have an archive of the corruption for posterity anyway)\n\nI would prefer to help straighten this out --- I have a company repo\nto fall back on, I have git 1.4 and other repos to fall back on, so\nI'm safe.\n\n> - if you don't, you can try \"git unpack-objects -r\". See the man-page on \n> why you need to first _move_ the pack-file away:\n>\n>\tmv .git/bad-pack.pack\n>\tmv .git/bad-index.index\n>\n>\tgit unpack-objects -r < .git/bad-pack.pack\n\nSince I can reproduce the error fairly readily, I can do this later.\n\n>Finally: it would be very interesting to hear if you do something strange \n>or unusual that could have made your chances of getting corruption higher.\n>\n>Have you ever seen random SIGSEV's or strange oopses, which could be a \n>sign of memory corruption on your machine? Do you do a lot of things over \n>NFS? (which really can corrupt things, especially in circumstances with \n>dodgy ethernet chips: the UDP checksums are very weak, and some ethernet \n>cards do not do a good job of checking the ethernet CRC's!).\n\nNo NFS, but I checked /var/log/messages. I see segfaults from git,\nthat I missed somehow (don't remember seeing anything awry on the\nterminal):\n\nFeb 14 10:05:07 lisa kernel: git[21648]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4\nFeb 14 10:05:43 lisa kernel: git[21710]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4\nFeb 14 10:06:28 lisa kernel: git[21858]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4\nFeb 14 10:10:04 lisa kernel: git[22385]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4\nFeb 14 11:01:56 lisa kernel: git[24446]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc888 error 4\nFeb 14 11:02:34 lisa kernel: git[24479]: segfault at 0000000000000000 rip 0000003f5eb70a40 rsp 0000007fbfffc868 error 4\nFeb 14 11:02:40 lisa kernel: git[24700]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc868 error 4\nFeb 14 11:07:51 lisa kernel: git[24844]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc128 error 4\nFeb 14 11:07:52 lisa kernel: git[24855]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc128 error 4\nFeb 14 11:08:01 lisa kernel: git[24886]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc128 error 4\nFeb 14 11:08:06 lisa kernel: git[24897]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc118 error 4\nFeb 14 11:08:09 lisa kernel: git[24908]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc118 error 4\nFeb 14 11:08:27 lisa kernel: git[24939]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4\n\n10:05 is just before I posted my first note of this to the git list, and\nthe first instance of a segfault that I see.\n\n>And if you can make the git history available to outsiders, I'd love to \n>see the corrupt tar-file (it doesn't have to be *public*, if you just can \n>trust me and perhaps a few other people with the data).\n\nAgain, please let me know who to contact about helping on this.\n\n\nBill\n"},{"id":"34630","messageId":"Pine.LNX.4.64.0702141603440.1757@xanadu.home","threadId":"6820","inReplyTo":"17875.30187.289679.417079@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-14T21:14:40Z","receivedAt":"2007-02-14T21:14:40Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 14 Feb 2007, Bill Lear wrote:\n\n> So (hopefully this is helpful) I look in my public repo for this pack\n> file:\n> \n> % ls -l /repos/git/fus/objects/pack\n> total 88420\n> -r--r--r-- 1 blear software 10376 Feb 14 10:06 pack-1a201381fe465cbf4d771aec681aff6e12648ea0.idx\n> -r--r--r-- 1 blear software 753437 Feb 14 10:06 pack-1a201381fe465cbf4d771aec681aff6e12648ea0.pack\n> -r--r--r-- 1 blear software 77360 Feb 13 10:57 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx\n> -r--r--r-- 1 blear software 89576130 Feb 13 10:57 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n> \n> and notice, it is different than the same pack on my just-cloned repo\n> (that is, the second clone, that I used to reproduce the first\n> failure):\n> \n> % ls -l objects/pack/\n> total 87632\n> -r--r--r-- 1 blear software 77360 Feb 14 12:50 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx\n> -r--r--r-- 1 blear software 89548154 Feb 14 12:52 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n> \n> and in my first-cloned repo:\n> \n> % ls -l objects/pack/\n> total 85992\n> -r--r--r-- 1 blear software 77360 Feb 13 10:18 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx\n> -r--r--r-- 1 blear software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n> \n> The .pack files have the same SHA, but different sizes (don't know\n> what that means).\n\nThe name of the pack corresponds to the list of objects it contains. \nThe way those objects are packed can change the size and the raw content \nof the pack file, but they still should contain the equivalent data. So \nthis size difference is not a sign of problem.\n\n\nNicolas\n"},{"id":"34631","messageId":"17875.31922.333264.948817@lisa.zopyra.com","threadId":"6820","inReplyTo":"7vmz3gmojt.fsf@assigned-by-dhcp.cox.net","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-14T21:18:42Z","receivedAt":"2007-02-14T21:18:42Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, February 14, 2007 at 13:12:22 (-0800) Junio C Hamano writes:\n>Bill Lear writes:\n>...\n>\"ldd ~/git-master/bin/git\" tells me that it links with libcrypto.so,\n>so I am using OpenSSL's SHA-1 implementation. I do not know\n>what your distro uses (or you hand built git yourself?).\n\nShould have known --- I hand-built it myself, and thought perhaps\nit was a configure option (output truncated):\n\n% ldd /opt/git-1.5.0/bin/git\n libcrypto.so.4 => /lib64/libcrypto.so.4 (0x0000003de1300000)\n% ldd /usr/bin/git\n libcrypto.so.4 => /lib64/libcrypto.so.4 (0x0000003de1300000)\n\nSo, both 1.5 and 1.4.4.1 are using OpenSSL, I reckon.\n\n>So it looks more and more like a bit decay as Linus suspected...\n\nStrange: given that fsck works on my public repo, with both 1.4.4.1\nand with 1.5.0, and I reproduced this easily and fsck barfs on\nboth of my failed repos. I can't imagine this is really a disk\nerror of any kind.\n\n\nBill\n"},{"id":"34633","messageId":"Pine.LNX.4.64.0702141314440.20368@woody.linux-foundation.org","threadId":"6820","inReplyTo":"17875.30687.661794.512124@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-14T21:19:29Z","receivedAt":"2007-02-14T21:19:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Feb 2007, Bill Lear wrote:\n>\n> I forgot to mention that fsck in my original public repo looks fine:\n> \n> % cd /repos/git/fus\n> \n> [with 1.4.4.1]\n> % GIT_DIR=. /usr/bin/git fsck-objects --full\n> dangling commit 828c0a0649d2d6b43ed13853bba33f7764f034fa\n> \n> [with 1.5.0]\n> % GIT_DIR=. git fsck-objects --full\n> dangling commit 828c0a0649d2d6b43ed13853bba33f7764f034fa\n\nAhh. So it's literally just the clone that fails?\n\nWhat happens if you do *just*\n\n\tgit clone /repos/git/fus new\n\tcd new\n\tgit fsck --full\n\nand nothing else?\n\n\t\tLinus\n"},{"id":"34637","messageId":"7vabzgmnn2.fsf@assigned-by-dhcp.cox.net","threadId":"6820","inReplyTo":"17875.30187.289679.417079@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-14T21:32:01Z","receivedAt":"2007-02-14T21:32:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bill Lear writes:\n\n> ... I did try doing this:\n>\n> 1) with 1.4.4.1 git, clone my public repo\n> 2) in this new clone, make modifications to my files as before\n> 3) with 1.5.0 git, do a commit\n>\n> and I got the same blowup on commit, and this on fsck, with 1.5.0 git:\n>\n> % git fsck-objects --full\n> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself\n> error: 00078437c23cbc04da52233f4f412219f88b8927: object corrupt or missing\n> fatal: unknown object type 5 in .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n\nIf you stop after cloning but before making a modification, is\nthe repository in good shape?\n\n> % ls -l objects/pack/\n> total 85992\n> -r--r--r-- 1 blear software 77360 Feb 13 10:18 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx\n> -r--r--r-- 1 blear software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n>\n> The .pack files have the same SHA, but different sizes (don't know\n> what that means).\n\nThat is usually not a problem; the name reflects the names of\nobjects contained in the pack (so both have the same set of\nobjects), but the actual raw contents (and the offsets recorded\nin corresponding .idx file) depends on the packing parameters\n(window, depth and deltabaseoffset).\n"},{"id":"34638","messageId":"Pine.LNX.4.64.0702141327240.20368@woody.linux-foundation.org","threadId":"6820","inReplyTo":"17875.31600.643352.808533@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-14T21:35:27Z","receivedAt":"2007-02-14T21:35:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Feb 2007, Bill Lear wrote:\n> \n> No NFS, but I checked /var/log/messages. I see segfaults from git,\n> that I missed somehow (don't remember seeing anything awry on the\n> terminal):\n> \n> Feb 14 10:05:07 lisa kernel: git[21648]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4\n> Feb 14 10:05:43 lisa kernel: git[21710]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4\n> Feb 14 10:06:28 lisa kernel: git[21858]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4\n>\n> 10:05 is just before I posted my first note of this to the git list, and\n> the first instance of a segfault that I see.\n\nOk, this is almost certainly what's up. For some strange reason your git \nbinary segfaults on the clone. The scary thing is, it left your cloned \nrepo in a bad state without even telling you. That's not good. Normally \nwe should always die() and give a _reason_ for a failure.\n\nIf you have that particular git binary, doing a\n\n\tgdb git\n\nand then at the gdb prompt doing\n\n\tx/5i 0x0000003f5eb709d0\n\nwill at least tell where the SIGSEGV happened, but it doesn't give a \nbacktrace so unless it's obvious, it can be a bit hard to debug remotely..\n\n\t\t\tLinus\n"},{"id":"34639","messageId":"17875.33204.413186.355557@lisa.zopyra.com","threadId":"6820","inReplyTo":"Pine.LNX.4.64.0702141314440.20368@woody.linux-foundation.org","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-14T21:40:04Z","receivedAt":"2007-02-14T21:40:04Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"WAAAAAIAMINIT ... I think I see it:\n\n% perl -pi -e 's/.*\\$Id.*//sx' $(xgrep -l '[$]Id')\n\nCould I have corrupted the pack file? I'll bet $50 I did:\n\n% [yet another clone]\n% xgrep -l '[$]Id'\n./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n[...]\n\n%!@#$&$%(@@@!!!\n\nI sent this list to a Perl script to nuke CVS Ids! I invoked this\none level up in my directories, not in my source tree, and .git\ngot picked up.\n\n[Really, Really Red Shame Face Here]\n\nOk, I win $50, and I owe each of you a bottle of very good wine for\nwasting your time. Just send me an email privately to tell me what\nyou prefer ... seriously, very seriously ....\n\nI am, however, still curious about the git segfaults in my\n/var/log/messages.\n\n\nBill\n"},{"id":"34640","messageId":"7vzm7gl8cf.fsf@assigned-by-dhcp.cox.net","threadId":"6820","inReplyTo":"17875.33204.413186.355557@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-14T21:47:44Z","receivedAt":"2007-02-14T21:47:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bill Lear writes:\n\n> WAAAAAIAMINIT ... I think I see it:\n>\n> % perl -pi -e 's/.*\\$Id.*//sx' $(xgrep -l '[$]Id')\n>\n> Could I have corrupted the pack file? I'll bet $50 I did:\n>\n> % [yet another clone]\n> % xgrep -l '[$]Id'\n> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n> [...]\n>\n> %!@#$&$%(@@@!!!\n\nWe all make mistakes. Thanks for being honest.\n\nThe segfaults could be from \"git commit\" codepath, not from when\nyou cloned. I could try corrupting a packfile in my repository\nand see where it dies, perhaps later.\n \n"},{"id":"34641","messageId":"7vvei4l84q.fsf@assigned-by-dhcp.cox.net","threadId":"6820","inReplyTo":"7vzm7gl8cf.fsf@assigned-by-dhcp.cox.net","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-14T21:52:21Z","receivedAt":"2007-02-14T21:52:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Bill Lear writes:\n>\n>> WAAAAAIAMINIT ... I think I see it:\n>>\n>> % perl -pi -e 's/.*\\$Id.*//sx' $(xgrep -l '[$]Id')\n>>\n>> Could I have corrupted the pack file? I'll bet $50 I did:\n>>\n>> % [yet another clone]\n>> % xgrep -l '[$]Id'\n>> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n>> [...]\n>>\n>> %!@#$&$%(@@@!!!\n>\n> We all make mistakes. Thanks for being honest.\n\nBy the way, I sometimes think it might be worth doing this:\n\n\t$ chmod a-r .git/\n\nWe always access files by explicit paths and never ask \"ls .git/foo*\"\nto find what are under .git/ directory.\n"},{"id":"34643","messageId":"Pine.LNX.4.63.0702142300300.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6820","inReplyTo":"17875.33204.413186.355557@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-14T22:02:19Z","receivedAt":"2007-02-14T22:02:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 14 Feb 2007, Bill Lear wrote:\n\n> I sent this list to a Perl script to nuke CVS Ids! I invoked this one \n> level up in my directories, not in my source tree, and .git got picked \n> up.\n\nDo not be embarassed. Yours truly managed something similar (actually, I \nwas running a script to kill all \\r from files supposed to be text, and I \nforgot the \"*\" in `find * -type f`), but _without_ a backup. That was fun.\n\nCiao,\nDscho\n"},{"id":"34644","messageId":"Pine.LNX.4.63.0702142303250.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6820","inReplyTo":"7vvei4l84q.fsf@assigned-by-dhcp.cox.net","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-14T22:04:08Z","receivedAt":"2007-02-14T22:04:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 14 Feb 2007, Junio C Hamano wrote:\n\n> By the way, I sometimes think it might be worth doing this:\n> \n> \t$ chmod a-r .git/\n> \n> We always access files by explicit paths and never ask \"ls .git/foo*\" to \n> find what are under .git/ directory.\n\nIf so, please make it unconfigurable. I use tab-completion in the git \ndirectory quite often.\n\nCiao,\nDscho\n"},{"id":"34645","messageId":"7vire4l76a.fsf@assigned-by-dhcp.cox.net","threadId":"6820","inReplyTo":"Pine.LNX.4.63.0702142303250.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-14T22:13:01Z","receivedAt":"2007-02-14T22:13:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Wed, 14 Feb 2007, Junio C Hamano wrote:\n>\n>> By the way, I sometimes think it might be worth doing this:\n>> \n>> \t$ chmod a-r .git/\n>> \n>> We always access files by explicit paths and never ask \"ls .git/foo*\" to \n>> find what are under .git/ directory.\n>\n> If so, please make it unconfigurable. I use tab-completion in the git \n> directory quite often.\n\nDo you mean \"configurable\"?\n\nI wonder what you are doing inside .git directory in the first\nplace. I never chdir() into it myself, but that may be because\nI practicaly live inside Emacs.\n"},{"id":"34646","messageId":"Pine.LNX.4.64.0702141722410.1757@xanadu.home","threadId":"6820","inReplyTo":"17875.33204.413186.355557@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-14T22:27:24Z","receivedAt":"2007-02-14T22:27:24Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 14 Feb 2007, Bill Lear wrote:\n\n> WAAAAAIAMINIT ... I think I see it:\n> \n> % perl -pi -e 's/.*\\$Id.*//sx' $(xgrep -l '[$]Id')\n> \n> Could I have corrupted the pack file? I'll bet $50 I did:\n> \n> % [yet another clone]\n> % xgrep -l '[$]Id'\n> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n> [...]\n> \n> %!@#$&$%(@@@!!!\n\nBut...... your pack file is read-only, isn't it?\n\nIs perl -i so bad to overwrite even read only files?\n\n\nNicolas\n"},{"id":"34647","messageId":"Pine.LNX.4.63.0702142321390.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6820","inReplyTo":"7vire4l76a.fsf@assigned-by-dhcp.cox.net","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-14T22:32:17Z","receivedAt":"2007-02-14T22:32:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 14 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Wed, 14 Feb 2007, Junio C Hamano wrote:\n> >\n> >> By the way, I sometimes think it might be worth doing this:\n> >> \n> >> \t$ chmod a-r .git/\n> >> \n> >> We always access files by explicit paths and never ask \"ls .git/foo*\" to \n> >> find what are under .git/ directory.\n> >\n> > If so, please make it unconfigurable. I use tab-completion in the git \n> > directory quite often.\n> \n> Do you mean \"configurable\"?\n\nNo. I meant \"unconfigurable\", since the sane default _would_ be a-r.\n\nBut then, I see that I was silly. This chmod is done on git-init time, and \neasy to undo _if_ you want it.\n\nSo, colour me a supporter of that feature.\n\n> I wonder what you are doing inside .git directory in the first place. \n> I never chdir() into it myself, but that may be because I practicaly \n> live inside Emacs.\n\n:-) Lucky you. Since long time, I became a vi user, not out of fun, but \nout of necessity. I had to work on many machines which had vi installed, \nbut not emacs. On some, my quota was not large enough to compile the \nbeast, so I eventually gave in.\n\nBack to the subject: Sometimes I just want to look if a certain file is \npresent. But I cannot be bothered to really type out \".git/index.lock\", \nbut rather I do \".g/i.\"...\n\nAnyway, here is a minimal (completely untested) patch to do what you \nproposed:\n\n-- snipsnap --\n\n[PATCH] init: create GIT_DIR non-readable\n\nWe access all files in GIT_DIR by name, so we do not really need it to be \nreadable. However, it is less easy to corrupt the repository \nunintentionally when it is not readable.\n\nThose who want to be able to see the contents of GIT_DIR, always can just \ndo a `chown u+r $GIT_DIR`.\n\nSigned-off-by: Johannes Schindelin \n\n---\n\n builtin-init-db.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-init-db.c b/builtin-init-db.c\nindex 12e43d0..8496269 100644\n--- a/builtin-init-db.c\n+++ b/builtin-init-db.c\n@@ -18,7 +18,7 @@\n \n static void safe_create_dir(const char *dir, int share)\n {\n-\tif (mkdir(dir, 0777) < 0) {\n+\tif (mkdir(dir, share ? 0777 : 0333) < 0) {\n \t\tif (errno != EEXIST) {\n \t\t\tperror(dir);\n \t\t\texit(1);\n"},{"id":"34650","messageId":"17875.36879.872210.264473@lisa.zopyra.com","threadId":"6820","inReplyTo":"Pine.LNX.4.64.0702141722410.1757@xanadu.home","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-14T22:41:19Z","receivedAt":"2007-02-14T22:41:19Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, February 14, 2007 at 17:27:24 (-0500) Nicolas Pitre writes:\n>On Wed, 14 Feb 2007, Bill Lear wrote:\n>> %!@#$&$%(@@@!!!\n>\n>But...... your pack file is read-only, isn't it?\n\nCorrect.\n\n>Is perl -i so bad to overwrite even read only files?\n\nIt is bad. Evil. I will sue Larry Wall for making me, an innocent,\nlook so foolish.\n\nI'm still muttering to myself that I could be that dumb...\n\n\nBill\n"},{"id":"34652","messageId":"Pine.LNX.4.64.0702141447290.20368@woody.linux-foundation.org","threadId":"6820","inReplyTo":"17875.33204.413186.355557@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-14T23:03:19Z","receivedAt":"2007-02-14T23:03:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Feb 2007, Bill Lear wrote:\n>\n> WAAAAAIAMINIT ... I think I see it:\n> \n> % perl -pi -e 's/.*\\$Id.*//sx' $(xgrep -l '[$]Id')\n> \n> Could I have corrupted the pack file? I'll bet $50 I did:\n\nHeh.\n\nI'm relieved git is off the hook, although I think we should still look at \nthat SIGSEGV. We might well have some situation where we react badly do a \ncorrupt pack (most likely, by having one of the object parsing routines \nreturn NULL, and then we follow that NULL pointer rather than saying \"bad \nobject\").\n\n> % [yet another clone]\n> % xgrep -l '[$]Id'\n> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n\nThis is just one reason I don't ever use 'find' on my source tree. I long \nago used to do\n\n\tfind . -name '*.c' | xargs grep ...\n\netc, but especially with git I have almost totally stopped using \"xargs \ngrep\" entirely - to the point where I actually end up importing tar-files \ninto new git archives just because I'm so used to \"git grep\".\n\nSo I would suggest that in order to avoid this in the future, you teach \nyour fingers to say \"git grep\" instead of \"xgrep\"., which I assume is just \nsome local alias of yours for \"find .. | xargs grep\"?\n\n\"git grep\" really works wonderfully well, and you could have just done\n\n\tperl -pi -e 's/.*\\$Id.*//sx' $(git grep -l '[$]Id')\n\ninstead.\n\n(\"git grep\" is much nicer than \"xargs grep\" in many other ways too. You \ncan ask it to limit itself to a certain pattern of filenames etc by doing\n\n\tgit grep -l '[$]Id' -- 'net/*.[ch]'\n\nas long as you realize that the name pattern for git grep considers '*' to \nact like '**' does for some shells - ie it globs against '/'too, so the \nabove will find any C and header files under the net/ directory, however \ndeep they are.. And you can ask it to grep in just a certain revision etc \ntoo).\n\nOnce you get used to \"git grep\", I bet you'll forget all about \"xgrep\", \nand won't have to worry about going into the .git/ directory by mistake \nany more.\n\nThere are other tricks you can do, but they are somewhat inconvenient. \nThey range from making \".git\" a symlink to somewhere else (to stop \n\"find\" from following it), and in your case, since you apparently already \nhave an \"xgrep\" alias for this, you could just teach your \"find\" thing to \ndo something like what we do in the kernel Makefile:\n\n\tRCS_FIND_IGNORE := \\( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS -o -name .pc -o -name .hg -o -name .git \\) -prune -o\n\nand then we use\n\n\tfind . $(RCS_FIND_IGNORE) ...\n\nwhich knows to ignore \".git\" directories along with all the other \nSCCS/CVS/SVN/BK/etc directories.\n\n\t\tLinus\n"},{"id":"34654","messageId":"Pine.LNX.4.64.0702141516120.20368@woody.linux-foundation.org","threadId":"6820","inReplyTo":"Pine.LNX.4.64.0702141722410.1757@xanadu.home","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-14T23:24:32Z","receivedAt":"2007-02-14T23:24:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Feb 2007, Nicolas Pitre wrote:\n> \n> But...... your pack file is read-only, isn't it?\n\nAlmost any \"edit in place\" operation under UNIX is invariably a question \nof \"read old file + write new file + mv new old\". \n\nAs such, to be read-only for a lot of programs, you actually need to not \njust make the *file* read-only, you need to make the *directory* read-only \ntoo. \n\nOr you need to use only tools that explicitly check (a lot of editors will \ndo that, for example, because in an RCS world you're supposed to do magic \nthings to actually edit a file).\n\nSo I'm not at all surprised that \"-pi\" (where the \"i\" stands for \n\"in-place\") will overwrite read-only files.\n\nI'm sure there is some random character that makes perl check, and not do \nit. Probably a sequence of unusual characters that makes it look like a \nswear-word. \n\nMaybe \"perl -pi -%££@$\" will do it. And if not, just add random characters \nuntil it works. \"It's the perl way\".\n\n\tLinus \"Yeah, I never really got the 'perl way'\" Torvalds"},{"id":"34660","messageId":"er0a4k$n59$1@sea.gmane.org","threadId":"6820","inReplyTo":"7vire4l76a.fsf@assigned-by-dhcp.cox.net","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-15T00:41:40Z","receivedAt":"2007-02-15T00:41:40Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Johannes Schindelin writes:\n>> On Wed, 14 Feb 2007, Junio C Hamano wrote:\n>>\n>>> By the way, I sometimes think it might be worth doing this:\n>>> \n>>> $ chmod a-r .git/\n>>> \n>>> We always access files by explicit paths and never ask \"ls .git/foo*\" to \n>>> find what are under .git/ directory.\n>>\n>> If so, please make it unconfigurable. I use tab-completion in the git \n>> directory quite often.\n> \n> Do you mean \"configurable\"?\n> \n> I wonder what you are doing inside .git directory in the first\n> place. I never chdir() into it myself, but that may be because\n> I practicaly live inside Emacs.\n\nI look what interesting is in here (like COMMIT_EDITMSG, MERGE_HEAD,\nORIG_HEAD, some StGIT templates,....).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"34664","messageId":"20070215005431.GB94048@dspnet.fr.eu.org","threadId":"6820","inReplyTo":"7vire4l76a.fsf@assigned-by-dhcp.cox.net","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2007-02-15T00:54:31Z","receivedAt":"2007-02-15T00:54:31Z","isPatch":false,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Wed, Feb 14, 2007 at 02:13:01PM -0800, Junio C Hamano wrote:\n> I wonder what you are doing inside .git directory in the first\n> place. I never chdir() into it myself, but that may be because\n> I practicaly live inside Emacs.\n\n\"Hmmm, how did I call this remote already? ls .grem\nahhh, I see\".\n\nEmacs happily does the completion too, but obviously also requires +r\nfor that.\n\n OG.\n"},{"id":"34662","messageId":"45D3B4E7.8050408@fs.ei.tum.de","threadId":"6820","inReplyTo":"17875.36879.872210.264473@lisa.zopyra.com","subject":"OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-02-15T01:18:31Z","receivedAt":"2007-02-15T01:18:31Z","isPatch":false,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Bill Lear wrote:\n> I'm still muttering to myself that I could be that dumb...\n\nStill better than trying to backup with\n\ntar czvf data* destfile.tar.gz\n\nautomatic tape backup is a real helper then :)\n\ncheers\n simon\n\n-- \nServe - BSD +++ RENT this banner advert +++ ASCII Ribbon /\"\\\nWork - Mac +++ space for low €€€ NOW!1 +++ Campaign \\ /\nParty Enjoy Relax | http://dragonflybsd.org Against HTML \\\nDude 2c 2 the max ! http://golden-apple.biz Mail + News / \\\n\n"},{"id":"34666","messageId":"Pine.LNX.4.63.0702150234230.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6820","inReplyTo":"20070215005431.GB94048@dspnet.fr.eu.org","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-15T01:36:53Z","receivedAt":"2007-02-15T01:36:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Feb 2007, Olivier Galibert wrote:\n\n> On Wed, Feb 14, 2007 at 02:13:01PM -0800, Junio C Hamano wrote:\n> > I wonder what you are doing inside .git directory in the first\n> > place. I never chdir() into it myself, but that may be because\n> > I practicaly live inside Emacs.\n> \n> \"Hmmm, how did I call this remote already? ls .grem\n> ahhh, I see\".\n\nHmm. That does not work for remotes which are stored in the config (which \nis the default nowadays)...\n\nSo, what you described is obviously wrong.\n\nBesides, \"git remote\" is way shorter. And it even completes if you \ninstalled the bash completion script!\n\nCiao,\nDscho\n"},{"id":"34670","messageId":"20070215021345.GB29732@spearce.org","threadId":"6820","inReplyTo":"45D3B4E7.8050408@fs.ei.tum.de","subject":"Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-15T02:13:45Z","receivedAt":"2007-02-15T02:13:45Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Simon 'corecode' Schubert wrote:\n> Bill Lear wrote:\n> >I'm still muttering to myself that I could be that dumb...\n> \n> Still better than trying to backup with\n> \n> tar czvf data* destfile.tar.gz\n> \n> automatic tape backup is a real helper then :)\n\nor manual backup to \"tape\", where the tape device supplied was\nthe only disk... SunOS 4 did not take too kindly to its kernel,\nswap space, root fs being overwritten...\n\nOddly enough, that system never booted again. Ever. We couldn't\neven get it to see external (CD-ROM) based media. SCSI controller\nalso failed during the \"tape\" backup.\n\n-- \nShawn.\n"},{"id":"34675","messageId":"Pine.LNX.4.64.0702141836510.20368@woody.linux-foundation.org","threadId":"6820","inReplyTo":"20070215021345.GB29732@spearce.org","subject":"Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-15T02:51:09Z","receivedAt":"2007-02-15T02:51:09Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Feb 2007, Shawn O. Pearce wrote:\n\n> Simon 'corecode' Schubert wrote:\n> > Bill Lear wrote:\n> > >I'm still muttering to myself that I could be that dumb...\n> > \n> > Still better than trying to backup with\n> > \n> > tar czvf data* destfile.tar.gz\n> > \n> > automatic tape backup is a real helper then :)\n> \n> or manual backup to \"tape\", where the tape device supplied was\n> the only disk... SunOS 4 did not take too kindly to its kernel,\n> swap space, root fs being overwritten...\n\nHey, I can beat that (stop me at any time you've heard this story. No? Ok, \nthen..)\n\nI auto-dialed my harddisk. \n\nI had this auto-dialer, that would send \"+++\" + \"atz\" + \"atdt...\" to dial \nthe number to the university dial-in farm that was always busy for hours \nat a time, and since I've never been much of a user interface person (\"No \nreally? Linus, please tell more! I would never have guessed!\"), it was \nbasically\n\n\tautodial /dev/ttyS1\n\nor something very similar. It was really stupid too, so if it got some \nother answer than \"BUSY\" or \"CONNECTED\" back (or timed out), it would just \ngo on to the next number and try again.\n\nAnyway, the smarter among you will already see how I by mistake filled up \none of my harddisk partitions with Hayes \"AT\" modem commands, and deleted \nmy Minix installation. AND THE BASTARD NEVER ANSWERED!\n\nThat was one big (perhaps _the_) impetus for just deciding to make Linux \ngood enough that I wouldn't need to actually reinstall Minix. Happily, it \nwas already able to bootstrap itself at that point, it just wasn't quite \nas good yet. I fixed that in short order, and indeed, I never did end up \nfeeding the 17 floppy disks into my computer to reinstall Minix.\n\nMoral of the story: \"Stupidity is what makes the world go round.\"\n\nOr something like that.\n\n\t\t\tLinus\n"},{"id":"34681","messageId":"20070215084059.GA5428@informatik.uni-freiburg.de","threadId":"6820","inReplyTo":"17875.33204.413186.355557@lisa.zopyra.com","subject":"Re: Error converting from 1.4.4.1 to 1.5.0?","fromName":"Uwe Kleine-König","fromEmail":"ukleinek@informatik.uni-freiburg.de","sentAt":"2007-02-15T08:40:59Z","receivedAt":"2007-02-15T08:40:59Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Bill Lear wrote:\n> WAAAAAIAMINIT ... I think I see it:\n> \n> % perl -pi -e 's/.*\\$Id.*//sx' $(xgrep -l '[$]Id')\n> \n> Could I have corrupted the pack file? I'll bet $50 I did:\n> \n> % [yet another clone]\n> % xgrep -l '[$]Id'\n> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack\n> [...]\n> \n> %!@#$&$%(@@@!!!\nI suffered from something like that, too. Since then I have a script\n\"ufind\". It's a wrapper around find that ignores CVS, Subversion, Git\nand hg metadata. Then \"my\" command would be:\n\n\t$ ufind -type f -print0 | xargs -0 -r grep -lZ '[$]Id' | xargs -r perl -p -i -e 's/.../'\n\n\nWhere ... is something more restrictive that your .*\\$Id.*\n\nFor the interessted the script is attached.\n\n-- \nUwe Kleine-König\n\ncat /*dev/null; echo 'Hello World!';\ncat > /dev/null <<*/ \n() { } int main() { printf(\"Hello World!\\n\");}\n/* */\n\n\n#! /usr/bin/env python\n# Copyright (C) Uwe Zeisberger\n\nimport itertools, os, sys\n\nignoreexpr = ['-type', 'd', '(', '-name', 'CVS', '-o', '-name', '.svn', '-o', '-name', '.git', '-o', '-name', '.hg', ')']\npaths = list(itertools.takewhile(lambda x: x[0] not in '-(),!', sys.argv[1:]))\n\nargs = sys.argv[1 + len(paths):] or ['-true']\n\nos.execvp('find', ['find'] + paths + ['('] + ignoreexpr + [')', '-prune', '-false', '-o', '-not', '('] + ignoreexpr + [')', '('] + args + [')'])\n\n"},{"id":"34683","messageId":"200702150914.01361.andyparkins@gmail.com","threadId":"6820","inReplyTo":"45D3B4E7.8050408@fs.ei.tum.de","subject":"Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-15T09:13:52Z","receivedAt":"2007-02-15T09:13:52Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 February 15 01:18, Simon 'corecode' Schubert wrote:\n\n> > I'm still muttering to myself that I could be that dumb...\n\nHow about this:\n\n1) \"I should like to clean up root's home directory\"\n2) cd /root; ls -la .\n3) \"Oh, there are a lot of config file in this directory that I don't need any\n more\"\n4) rm -rf .*\n\nNow start crying softly to yourself, when you realise that \"..\" is covered \nby \".*\". Now go to every computer you work on and put\n\n export GLOBIGNORE=\".:..\"\n\nIn your .bashrc.\n\nBoy, was my face red...\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"34691","messageId":"Pine.LNX.4.63.0702151103100.448@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6820","inReplyTo":"Pine.LNX.4.64.0702141836510.20368@woody.linux-foundation.org","subject":"Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-15T10:24:20Z","receivedAt":"2007-02-15T10:24:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 14 Feb 2007, Linus Torvalds wrote:\n\n> On Wed, 14 Feb 2007, Shawn O. Pearce wrote:\n> \n> > Simon 'corecode' Schubert wrote:\n> > > Bill Lear wrote:\n> > > >I'm still muttering to myself that I could be that dumb...\n> > > \n> > > Still better than trying to backup with\n> > > \n> > > tar czvf data* destfile.tar.gz\n> > > \n> > > automatic tape backup is a real helper then :)\n> > \n> > or manual backup to \"tape\", where the tape device supplied was\n> > the only disk... SunOS 4 did not take too kindly to its kernel,\n> > swap space, root fs being overwritten...\n> \n> Hey, I can beat that (stop me at any time you've heard this story. No? \n> Ok, then..)\n\nWe're having a dick contest? Well, I'm game.\n\n> I auto-dialed my harddisk. \n\nI connected a tape drive.\n\nIt was a SCSI tape drive, and I had a SCSI Zip drive, which was so often \nconnected/disconnected in-flight that the plug wore out. So I thought that \nit should not be a problem to connect the SCSI tape drive to a running \nsystem. Right? RIGHT?\n\nBIG MISTAKE.\n\nThe SCSI adapter also hosted two RAID systems, one as a SCSI RAID, i.e. \nmanaged by the adapter, and one as ATAPI RAID, i.e. managed by its own \nembedded computer simulating one (actually, two) SCSI hard disks to the \nSCSI adapter.\n\nWe wanted to backup some of the data, and that's why we connected the tape \ndrive.\n\nFirst, we got write errors on the RAID. Then, one RAID (the SCSI one) \nstopped working at all. The fans still moved air, but the bus no longer \nmoved _any_ bytes.\n\nPanicked (Douglas Adams, where are you when I need you?), I disconnected \nthe tape drive, and the two RAID boxes (all of them were external, so \nthat was possible). I shut down the computer and let out a long breath of \nhope.\n\nIn the course of several weeks, my days started with praying, connecting \none or both RAIDs to several SCSI adapter/computer pairings, hoping that I \ncould read _anything_ from them.\n\nAll of the data was lost. Four terabytes. 6-7 months work of three people. \n\nTo this date, the SCSI RAID is not working. After one week (through which \nit did not work _at all_), the ATAPI RAID worked again (strangely enough), \nbut had lost the correct order of its 14 disks.\n\nEven if I could reconstruct the correct order after two more weeks, I \ncould not get any data from the RAID, since I had nowhere nearly large \nenough amounts of free disk space. And I could not teach the RAID the \ncorrect order.\n\nAnd the tape drive still does not work.\n\nOkay, guys, top _that_.\n\nCiao,\nDscho\n"},{"id":"34703","messageId":"17876.19166.796821.477083@lisa.zopyra.com","threadId":"6820","inReplyTo":"Pine.LNX.4.64.0702141836510.20368@woody.linux-foundation.org","subject":"Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-15T11:58:22Z","receivedAt":"2007-02-15T11:58:22Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, February 14, 2007 at 18:51:09 (-0800) Linus Torvalds writes:\n>On Wed, 14 Feb 2007, Shawn O. Pearce wrote:\n>> Simon 'corecode' Schubert wrote:\n>> > Bill Lear wrote:\n>> > >I'm still muttering to myself that I could be that dumb...\n>> > \n>> > Still better than trying to backup with\n>> > \n>> > tar czvf data* destfile.tar.gz\n>> > \n>> > automatic tape backup is a real helper then :)\n>> \n>> or manual backup to \"tape\", where the tape device supplied was\n>> the only disk... SunOS 4 did not take too kindly to its kernel,\n>> swap space, root fs being overwritten...\n>\n>Hey, I can beat that (stop me at any time you've heard this story. No? Ok, \n>then..)\n>\n>I auto-dialed my harddisk. \n>...\n>That was one big (perhaps _the_) impetus for just deciding to make Linux \n>good enough that I wouldn't need to actually reinstall Minix. ...\n>was already able to bootstrap itself at that point, it just wasn't quite \n>as good yet. I fixed that in short order, and indeed, I never did end up \n>feeding the 17 floppy disks into my computer to reinstall Minix.\n>\n>Moral of the story: \"Stupidity is what makes the world go round.\"\n\nAgreed. I often think stupid mistakes are a way of injecting random\n--- and at the time, unwelcome --- searches into creative solution\nspaces.\n\nAs in other cases, this one involved an extremely simple answer very\nclose to the start of the solution space, but (thanks to me), we drug\nthis out all over the place and got to explore lots of things we\notherwise wouldn't have.\n\n\nBill\n"},{"id":"34708","messageId":"f2b55d220702150513n3b6cfc37kc336b452155b5b94@mail.gmail.com","threadId":"6820","inReplyTo":"Pine.LNX.4.63.0702151103100.448@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)","fromName":"Michael K. Edwards","fromEmail":"medwards.linux@gmail.com","sentAt":"2007-02-15T13:13:43Z","receivedAt":"2007-02-15T13:13:43Z","isPatch":false,"sender":{"key":"medwards.linux@gmail.com","avatar":null},"body":"Not quite in the same vein, but perhaps amusing to Silicon Valley veterans:\n\nI worked for several years for a 64-bit processor + workstation vendor\nthat shall remain nameless. There was this one guy in the other\nbuilding who built the kernels for the 64-bit UNIX variant that\nshipped with US models. He had a SunOS 4 box on his desk that\nhappened to be the only machine in the world where his magic\n32-to-64-bit cross-compiler generated working kernels, for reasons no\none ever fully understood. The external SCSI died one day, and either\nthere were no backups or they wouldn't restore cleanly. I don't think\nthey ever shipped another kernel update.\n\nI can't swear to the accuracy of that story, though; my mind was on\nthe million-dollar \"high availability\" NFS server deployment I was\nswept up in. The vendor never did get the electricals straight on the\nshared SCSI bus, possibly because we had shelled out for redundant\npower supplies via independent UPSes all the way out to the backup\ngenerator, probably creating a gimongous ground loop. Kept frying the\nthird-party SCSI cards that were the key to the whole system, and\nscrambled the contents of the terabyte RAID more than once. I don't\nthink those backups ever worked, either. The whole kit got ripped out\nafter some months of chaos and replaced with in-house gear, which\nnever worked right either.\n\nSomewhere along the way, I figured out that the whole company (a U.S.\nsubsidiary of a Japanese multinational) was a clever arbitrage of the\nJapanese tax system. As I understand it, they got tax credits for\nforeign direct investment each quarter, then turned around and sent\nmost of the check back to the parent company to purchase custom DIMMs\nat absurd prices, earning yet more tax credits for export in a\ncritical high-tech product sector. They made a tidy profit at the\nJapanese taxpayers' expense even if we accomplished nothing\nwhatsoever.\n\nThe dedicated chip design and verification team didn't seem to have\ncottoned onto this, though, and went through literally dozens of spins\n(using the parent's semiconductor manufacturing division, natch).\nTheir design simulated substantially correctly at the logic level\n(nothing you couldn't work around in the compiler) from the beginning,\nbut actual fabrication exposed problem after problem in the cell\nlibrary associated with the parent company's recent process shrink.\n(Naturally, the NRE sent back to the parent for each chip spin also\nqualified for super-duper tax credits.)\n\nBy the time the similar processor division back in Japan went through\nthe same shrink, the cell library and design rule kinks were all\nworked out. So they got working silicon on the first spin where the\nlogic was correct (which was not, if I recall correctly, anything\nclose to the first spin; but they probably weren't charged NRE).\nGuess which division took the fall? Hint: the tax credits expired in\n2001, and so did the US subsidiary. They got another tax credit for\nliquidation losses, of course. Legend at the time had it that the\ncompany had never had a break-even quarter in 11 years of existence,\nand had burned more actual cash than any Silicon Valley startup of its\nera. (In retrospect the numbers don't appear to support the latter\nclaim.)\n\nI got to do some fun stuff while I was there, though, including a\nFrankenstein monster of an encrypted CVS transport that slotted SSLeay\ninto the GSSAPI interface intended for Kerberos. (Given the choice of\nKerberizing the site or running our own CA for client certs, we picked\nthe latter.) Although we had the source to Solaris, UnixWare, and\nWindows NT all under one roof, the \"secure\" version control was not\nfor any of these. It was reserved for the real crown-jewels-on-loan:\nthe source to the OpenBoot PROM. Go figure.\n\nCheers,\n- Michael\n"},{"id":"34710","messageId":"slrnet8rkc.sbe.mdw@metalzone.distorted.org.uk","threadId":"6820","inReplyTo":"200702150914.01361.andyparkins@gmail.com","subject":"Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)","fromName":"Mark Wooding","fromEmail":"mdw@distorted.org.uk","sentAt":"2007-02-15T14:30:36Z","receivedAt":"2007-02-15T14:30:36Z","isPatch":false,"sender":{"key":"mdw@distorted.org.uk","avatar":null},"body":"Andy Parkins wrote:\n\n> 4) rm -rf .*\n\nI'm nowhere near that impressive, unfortunately.\n\nOnce upon a time, I was trying to build some package (I forget which)\nfrom its source distribution. It was an GNU-y Autoconf kind of thing.\nI didn't want to install it globally at that point, just in my home\ndirectory. So I said\n\n $ ./configure --prefix=~\n $ make\n $ make install\n\nSo far, so good. Now try to run the thing.\n\n $ foo\n bash: foo: command not found\n\nOh. Where's it gone?\n\n $ ls\n\nThat's annoying. Bad shell. It's failed to expand `~', and just put\neverything in a directory called `~' in my build tree. Bugger. I don't\nwant it there.\n\n $ rm -rf ~\n\nI wonder why it's taking so lo... ^C^C^C^C\n\n-- [mdw]\n"}]}