Error converting from 1.4.4.1 to 1.5.0?

Error converting from 1.4.4.1 to 1.5.0?

[Bill Lear]

I have a 1.4.4.1 repository, non-bare, cloned from my public
repository.  I just installed and am using the new 1.5.0 git.

On my master branch, I cleaned out some cvs ids in our text files and
did a git diff --- all was well.

I then did a commit, and something went wrong:

% git commit -a -m "Nuke CVS Id strings"
error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
error: unable to read tree object HEAD
# On branch master
error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
error: unable to read tree object HEAD
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       src/ledef/
nothing added to commit but untracked files present (use "git add" to track)

The "Untracked files:" part is fine, but what's up with the other
errors?

I now do a git status and it shows all of my files that I changed
as still modified, and git diff seems to show the same output.


Bill

Re: Error converting from 1.4.4.1 to 1.5.0?

[Bill Lear]

On Wednesday, February 14, 2007 at 10:12:44 (-0600) Bill Lear writes:
>I have a 1.4.4.1 repository, non-bare, cloned from my public
>repository.  I just installed and am using the new 1.5.0 git.
>
>On my master branch, I cleaned out some cvs ids in our text files and
>did a git diff --- all was well.
>
>I then did a commit, and something went wrong:
>
>% git commit -a -m "Nuke CVS Id strings"
>error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
>error: unable to read tree object HEAD
># On branch master
>error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
>error: unable to read tree object HEAD
>...

I also notice this:

% git diff src/fus/testsuite/fus.design/prep4_5.s
fatal: failed to find delta-pack base object 1e742ba82e01f5bb39ed62e6863712fd3c9b0616
diff --git a/src/fus/testsuite/fus.design/prep4_5.s b/src/fus/tes[...]
index 106a233..4e6dbd5 100644

But running diff again seems to make the warning go away, but no
changes are listed...bad.


Bill

Re: Error converting from 1.4.4.1 to 1.5.0?

[Junio C Hamano]

Bill Lear <rael@zopyra.com> writes:

> I then did a commit, and something went wrong:
>
> % git commit -a -m "Nuke CVS Id strings"
> error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
> error: unable to read tree object HEAD
> # On branch master
> error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
> error: unable to read tree object HEAD

Does 1.4.4 find that object?  What's in HEAD (cat .git/HEAD)?
What does "git fsck-objects --full" report?

Re: Error converting from 1.4.4.1 to 1.5.0?

[Bill Lear]

On Wednesday, February 14, 2007 at 09:15:08 (-0800) Junio C Hamano writes:
>Bill Lear <rael@zopyra.com> writes:
>
>> I then did a commit, and something went wrong:
>>
>> % git commit -a -m "Nuke CVS Id strings"
>> error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
>> error: unable to read tree object HEAD
>> # On branch master
>> error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
>> error: unable to read tree object HEAD
>
>Does 1.4.4 find that object?  What's in HEAD (cat .git/HEAD)?
>What does "git fsck-objects --full" report?

% cat .git/HEAD
ref: refs/heads/master

% git --version
git version 1.5.0-dirty

% git fsck-objects --full
error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27

% /usr/bin/git --version
git version 1.4.4.1

% /usr/bin/git fsck-objects --full
error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27

So, all I did was try to do a commit with the new git ... haven't
recloned, or pulled from upstream...



Bill

Re: Error converting from 1.4.4.1 to 1.5.0?

[Junio C Hamano]

Bill Lear <rael@zopyra.com> writes:

> % git fsck-objects --full
> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
>
>
> % /usr/bin/git --version
> git version 1.4.4.1
>
> % /usr/bin/git fsck-objects --full
> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
>
> So, all I did was try to do a commit with the new git ... haven't
> recloned, or pulled from upstream...

If you haven't packed the repository lately, the above indicates
this is not an issue between 1.4.4.1 and 1.5.0, but you had a
corrupt packfile before even started.

How big is this pack, what platform are you working on and whose
SHA-1 implementation do you use?

We used to have a bug that fed really large buffer to
SHA1_Update() function of the underlying SHA-1 library,
which was discovered exactly because somebody reported that
"mismatch with itself" message.

Also, do you have a huge blob in the repository?  I do not know
if it is related but the write_sha1_file_prepare() function on
the codepath to write loose objects out would trigger the same
bug...

Re: Error converting from 1.4.4.1 to 1.5.0?

[Linus Torvalds]

On Wed, 14 Feb 2007, Bill Lear wrote:
>
> % git fsck-objects --full
> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself

This in itself could have been due to a historical buglet that shouldn't 
matter (SHA1 on pack-files got miscomputed). However, that's probably NOT 
the problem, since:

> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27

implies that the pack really is corrupt.

Even a single-bit error will corrupt a pack in bad ways, which is one 
reason why we're so careful with it and add its own SHA1 to the end.

The best way to proceed:

 - MAKE A BACKUP ("tar" up everything). If for no other reason than

   (a) then you don't have to worry about making things worse even by 
       mistake
   (b) it might be interesting for others (if you can make those 
       pack-files available) to try to figure out what exactly the 
       corruption was. We've done it before, when it turned out to be a 
       single-bit error.

 - if you have other git archives or just back-ups of everything, just use 
   them, and throw the corrupt one away entirely (but see above on why 
   it's nice to have an archive of the corruption for posterity anyway)

 - if you don't, you can try "git unpack-objects -r". See the man-page on 
   why you need to first _move_ the pack-file away:

	mv <bad-pack-file> .git/bad-pack.pack
	mv <bad-pack-index> .git/bad-index.index

	git unpack-objects -r < .git/bad-pack.pack

   this will unpack as many objects into loose format as it can. Hopefully 
   you haven't lost much.

 - after that, the ones that you *did* lose, you can hopefully find in 
   older git repos: even if you didn't have the *full* new repo anywhere 
   else, other git repositories may have the particular objects that got 
   corrupted. "git fsck" will tell you what is missing, and you can just 
   point your .git/info/alternates file at other repositories to "steal" 
   objects from automatically.

 - if you aren't missing any objects after that, you can now repack the 
   repository, and then remove the alternates file:

	git repack -a -d
	rm .git/info/alternates

   because the repack will steal all the objects you need, and thus you 
   don't need alternates any more.

Finally: it would be very interesting to hear if you do something strange 
or unusual that could have made your chances of getting corruption higher.

Have you ever seen random SIGSEV's or strange oopses, which could be a 
sign of memory corruption on your machine? Do you do a lot of things over 
NFS? (which really can corrupt things, especially in circumstances with 
dodgy ethernet chips: the UDP checksums are very weak, and some ethernet 
cards do not do a good job of checking the ethernet CRC's!).

> So, all I did was try to do a commit with the new git ... haven't
> recloned, or pulled from upstream...

Yes, don't do anything more (certainly do *not* repack or anything) until 
you have tarred up and saved the current state, and then only _after_ you 
have a good safe archive to restart from, try to fix it up.

And if you can make the git history available to outsiders, I'd love to 
see the corrupt tar-file (it doesn't have to be *public*, if you just can 
trust me and perhaps a few other people with the data).

So far, as far as I can recall, we've certainly had people screw up their 
own trees by mistake, but apart from that kind of "user error" things, the 
only real corruption I recall was the single-bit error in a pack-file. We 
were able to recover that, but in general, for safety, the best way to 
protect your data is to replicate it across multiple independent machines 
(something that git is _good_ at, happily).

		Linus

Re: Error converting from 1.4.4.1 to 1.5.0?

[Linus Torvalds]

On Wed, 14 Feb 2007, Linus Torvalds wrote:
> 
> And if you can make the git history available to outsiders, I'd love to 
> see the corrupt tar-file (it doesn't have to be *public*, if you just can 
> trust me and perhaps a few other people with the data).

Side note: one reason why this is nice - even if you don't care about the 
corruption and can fix it other ways - is that the last time we had the 
one-bit corruption is also the reason why we now have the "-r" option to 
git-unpack-objects.

In other words, real-life corruption is not just a really nasty event, 
it's also a good way for *us* to verify that our recovery tools do as good 
a job as they possibly can. Maybe there are other things like that "-r" 
option where we could possibly do even better.

The git data structures are designed to be extremely robust, but there's 
nothing they can do about "corruption after the fact". The same way that a 
logging filesystem doesn't help if the disk itself starts getting read 
errors, the git data structures aren't going to guarantee that you can't 
lose data if you have actual disk or memory corruption going on. 

The things git can do is:

 - detection. The SHA1's should basically guarantee that you will never 
   ever have an _undetectable_ corruption anywhere (which is really really 
   easy with just about any other SCM)

 - make replication easy (so that once you've detected corruption, you 
   have mirrors you can trust).

 - and finally: in the absense of replication, we can do  our damndest to 
   try to figure out what the data was. But in many ways, the fact that we 
   are really really good at compressing data (people do love their small 
   repositories) also means that we have basically no redundancy anywhere, 
   because redundancy is what compression gets rid of (both delta- and 
   zlib compression do it - it's very fundamentally what any compression 
   is based on)

but it's always interesting to have real-life corruption cases to verify.

			Linus

Re: Error converting from 1.4.4.1 to 1.5.0?

[Bill Lear]

On Wednesday, February 14, 2007 at 09:45:14 (-0800) Junio C Hamano writes:
>Bill Lear <rael@zopyra.com> writes:
>
>> % git fsck-objects --full
>> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
>> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
>>
>>
>> % /usr/bin/git --version
>> git version 1.4.4.1
>>
>> % /usr/bin/git fsck-objects --full
>> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
>> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
>>
>> So, all I did was try to do a commit with the new git ... haven't
>> recloned, or pulled from upstream...
>
>If you haven't packed the repository lately, the above indicates
>this is not an issue between 1.4.4.1 and 1.5.0, but you had a
>corrupt packfile before even started.
>
>How big is this pack, what platform are you working on and whose
>SHA-1 implementation do you use?

In order:

% cd .git/objects/pack
% ls -l
-r--r--r--  1 rael software    77360 Feb 13 10:18 pack-23d1a9af78b4b78d...
-r--r--r--  1 rael software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d...

[output of ls trimmed to width]

% uname -a
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

I don't know which SHA-1 implementation I use --- I just installed git
and off I went.  I do see this:

% which sha1sum
/usr/bin/sha1sum
% sha1sum --version
shasum (coreutils) 5.2.1
Written by Ulrich Drepper and Scott Miller.
[...]

But I'm not sure which library is in use --- how do I know?

>Also, do you have a huge blob in the repository?  I do not know
>if it is related but the write_sha1_file_prepare() function on
>the codepath to write loose objects out would trigger the same
>bug...

I don't know what "huge" is, but the pack file seems to be the largest
and then one of the objects is listed at 28,604,986 bytes, but nothing
else is very large.

So, before I get to Linus's message, I did try doing this:

1) with 1.4.4.1 git, clone my public repo
2) in this new clone, make modifications to my files as before
3) with 1.5.0 git, do a commit

and I got the same blowup on commit, and this on fsck, with 1.5.0 git:

% git fsck-objects --full
error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
error: 00078437c23cbc04da52233f4f412219f88b8927: object corrupt or missing
fatal: unknown object type 5 in .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack

and with 1.4.4.1 git:

% /usr/bin/git fsck-objects --full
error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
fatal: corrupted pack file .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack

So (hopefully this is helpful) I look in my public repo for this pack
file:

% ls -l /repos/git/fus/objects/pack
total 88420
-r--r--r--  1 blear software    10376 Feb 14 10:06 pack-1a201381fe465cbf4d771aec681aff6e12648ea0.idx
-r--r--r--  1 blear software   753437 Feb 14 10:06 pack-1a201381fe465cbf4d771aec681aff6e12648ea0.pack
-r--r--r--  1 blear software    77360 Feb 13 10:57 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
-r--r--r--  1 blear software 89576130 Feb 13 10:57 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack

and notice, it is different than the same pack on my just-cloned repo
(that is, the second clone, that I used to reproduce the first
failure):

% ls -l objects/pack/
total 87632
-r--r--r--  1 blear software    77360 Feb 14 12:50 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
-r--r--r--  1 blear software 89548154 Feb 14 12:52 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack

and in my first-cloned repo:

% ls -l objects/pack/
total 85992
-r--r--r--  1 blear software    77360 Feb 13 10:18 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
-r--r--r--  1 blear software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack

The .pack files have the same SHA, but different sizes (don't know
what that means).

I will continue digging and on to Linus's post...


Bill

Re: Error converting from 1.4.4.1 to 1.5.0?

[Bill Lear]

I forgot to mention that fsck in my original public repo looks fine:

% cd /repos/git/fus

[with 1.4.4.1]
% GIT_DIR=. /usr/bin/git fsck-objects --full
dangling commit 828c0a0649d2d6b43ed13853bba33f7764f034fa

[with 1.5.0]
% GIT_DIR=. git fsck-objects --full
dangling commit 828c0a0649d2d6b43ed13853bba33f7764f034fa


Bill

Re: Error converting from 1.4.4.1 to 1.5.0?

[Junio C Hamano]

Bill Lear <rael@zopyra.com> writes:

>>How big is this pack, what platform are you working on and whose
>>SHA-1 implementation do you use?
>
> In order:
>
> % cd .git/objects/pack
> % ls -l
> -r--r--r--  1 rael software    77360 Feb 13 10:18 pack-23d1a9af78b4b78d...
> -r--r--r--  1 rael software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d...
>
> [output of ls trimmed to width]
>
> % uname -a
> 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
>
> I don't know which SHA-1 implementation I use --- I just installed git
> and off I went.  I do see this:
>
> % which sha1sum
> /usr/bin/sha1sum
> % sha1sum --version
> shasum (coreutils) 5.2.1
> Written by Ulrich Drepper and Scott Miller.
> [...]
>
> But I'm not sure which library is in use --- how do I know?

"ldd ~/git-master/bin/git" tells me that it links with libcrypto.so,
so I am using OpenSSL's SHA-1 implementation.  I do not know
what your distro uses (or you hand built git yourself?).

I asked this question, because... 

>>Also, do you have a huge blob in the repository?  I do not know
>>if it is related but the write_sha1_file_prepare() function on
>>the codepath to write loose objects out would trigger the same
>>bug...
>
> I don't know what "huge" is, but the pack file seems to be the largest
> and then one of the objects is listed at 28,604,986 bytes, but nothing
> else is very large.

... we had a problem that some SHA-1 implementation gave bogus
results when we did this:

	SHA_CTX ctx;
	unsigned char sha1[20];
      
	SHA1_Init(&ctx);
        /* hash len bytes starting from buf */
	SHA1_Update(&ctx, buf, len);
	SHA1_Final(sha1, &ctx);

and asked to hash a large buffer in one go.  One of the SHA1
implementations we ship ourselves (I think it was handcrafted
PPC one) used to have problems.  But I do not think 27MB is
large enough to trigger such a library bug (the bug was integer
wraparound of a bit counter, I think).

So it looks more and more like a bit decay as Linus suspected...

Re: Error converting from 1.4.4.1 to 1.5.0?

[Bill Lear]

On Wednesday, February 14, 2007 at 10:19:53 (-0800) Linus Torvalds writes:
>On Wed, 14 Feb 2007, Bill Lear wrote:
>> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
>
>implies that the pack really is corrupt.
>...
>   (b) it might be interesting for others (if you can make those 
>       pack-files available) to try to figure out what exactly the 
>       corruption was. We've done it before, when it turned out to be a 
>       single-bit error.

If you could tell me who I should contact about this, I will.

> - if you have other git archives or just back-ups of everything, just use 
>   them, and throw the corrupt one away entirely (but see above on why 
>   it's nice to have an archive of the corruption for posterity anyway)

I would prefer to help straighten this out --- I have a company repo
to fall back on, I have git 1.4 and other repos to fall back on, so
I'm safe.

> - if you don't, you can try "git unpack-objects -r". See the man-page on 
>   why you need to first _move_ the pack-file away:
>
>	mv <bad-pack-file> .git/bad-pack.pack
>	mv <bad-pack-index> .git/bad-index.index
>
>	git unpack-objects -r < .git/bad-pack.pack

Since I can reproduce the error fairly readily, I can do this later.

>Finally: it would be very interesting to hear if you do something strange 
>or unusual that could have made your chances of getting corruption higher.
>
>Have you ever seen random SIGSEV's or strange oopses, which could be a 
>sign of memory corruption on your machine? Do you do a lot of things over 
>NFS? (which really can corrupt things, especially in circumstances with 
>dodgy ethernet chips: the UDP checksums are very weak, and some ethernet 
>cards do not do a good job of checking the ethernet CRC's!).

No NFS, but I checked /var/log/messages.  I see segfaults from git,
that I missed somehow (don't remember seeing anything awry on the
terminal):

Feb 14 10:05:07 lisa kernel: git[21648]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
Feb 14 10:05:43 lisa kernel: git[21710]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
Feb 14 10:06:28 lisa kernel: git[21858]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
Feb 14 10:10:04 lisa kernel: git[22385]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
Feb 14 11:01:56 lisa kernel: git[24446]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc888 error 4
Feb 14 11:02:34 lisa kernel: git[24479]: segfault at 0000000000000000 rip 0000003f5eb70a40 rsp 0000007fbfffc868 error 4
Feb 14 11:02:40 lisa kernel: git[24700]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc868 error 4
Feb 14 11:07:51 lisa kernel: git[24844]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc128 error 4
Feb 14 11:07:52 lisa kernel: git[24855]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc128 error 4
Feb 14 11:08:01 lisa kernel: git[24886]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc128 error 4
Feb 14 11:08:06 lisa kernel: git[24897]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc118 error 4
Feb 14 11:08:09 lisa kernel: git[24908]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc118 error 4
Feb 14 11:08:27 lisa kernel: git[24939]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4

10:05 is just before I posted my first note of this to the git list, and
the first instance of a segfault that I see.

>And if you can make the git history available to outsiders, I'd love to 
>see the corrupt tar-file (it doesn't have to be *public*, if you just can 
>trust me and perhaps a few other people with the data).

Again, please let me know who to contact about helping on this.


Bill

Re: Error converting from 1.4.4.1 to 1.5.0?

[Nicolas Pitre]

On Wed, 14 Feb 2007, Bill Lear wrote:

> So (hopefully this is helpful) I look in my public repo for this pack
> file:
> 
> % ls -l /repos/git/fus/objects/pack
> total 88420
> -r--r--r--  1 blear software    10376 Feb 14 10:06 pack-1a201381fe465cbf4d771aec681aff6e12648ea0.idx
> -r--r--r--  1 blear software   753437 Feb 14 10:06 pack-1a201381fe465cbf4d771aec681aff6e12648ea0.pack
> -r--r--r--  1 blear software    77360 Feb 13 10:57 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
> -r--r--r--  1 blear software 89576130 Feb 13 10:57 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
> 
> and notice, it is different than the same pack on my just-cloned repo
> (that is, the second clone, that I used to reproduce the first
> failure):
> 
> % ls -l objects/pack/
> total 87632
> -r--r--r--  1 blear software    77360 Feb 14 12:50 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
> -r--r--r--  1 blear software 89548154 Feb 14 12:52 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
> 
> and in my first-cloned repo:
> 
> % ls -l objects/pack/
> total 85992
> -r--r--r--  1 blear software    77360 Feb 13 10:18 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
> -r--r--r--  1 blear software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
> 
> The .pack files have the same SHA, but different sizes (don't know
> what that means).

The name of the pack corresponds to the list of objects it contains.  
The way those objects are packed can change the size and the raw content 
of the pack file, but they still should contain the equivalent data.  So 
this size difference is not a sign of problem.


Nicolas

Re: Error converting from 1.4.4.1 to 1.5.0?

[Bill Lear]

On Wednesday, February 14, 2007 at 13:12:22 (-0800) Junio C Hamano writes:
>Bill Lear <rael@zopyra.com> writes:
>...
>"ldd ~/git-master/bin/git" tells me that it links with libcrypto.so,
>so I am using OpenSSL's SHA-1 implementation.  I do not know
>what your distro uses (or you hand built git yourself?).

Should have known --- I hand-built it myself, and thought perhaps
it was a configure option (output truncated):

% ldd /opt/git-1.5.0/bin/git
        libcrypto.so.4 => /lib64/libcrypto.so.4 (0x0000003de1300000)
% ldd /usr/bin/git
        libcrypto.so.4 => /lib64/libcrypto.so.4 (0x0000003de1300000)

So, both 1.5 and 1.4.4.1 are using OpenSSL, I reckon.

>So it looks more and more like a bit decay as Linus suspected...

Strange: given that fsck works on my public repo, with both 1.4.4.1
and with 1.5.0, and I reproduced this easily and fsck barfs on
both of my failed repos.  I can't imagine this is really a disk
error of any kind.


Bill

Re: Error converting from 1.4.4.1 to 1.5.0?

[Linus Torvalds]

On Wed, 14 Feb 2007, Bill Lear wrote:
>
> I forgot to mention that fsck in my original public repo looks fine:
> 
> % cd /repos/git/fus
> 
> [with 1.4.4.1]
> % GIT_DIR=. /usr/bin/git fsck-objects --full
> dangling commit 828c0a0649d2d6b43ed13853bba33f7764f034fa
> 
> [with 1.5.0]
> % GIT_DIR=. git fsck-objects --full
> dangling commit 828c0a0649d2d6b43ed13853bba33f7764f034fa

Ahh. So it's literally just the clone that fails?

What happens if you do *just*

	git clone /repos/git/fus new
	cd new
	git fsck --full

and nothing else?

		Linus

Re: Error converting from 1.4.4.1 to 1.5.0?

[Junio C Hamano]

Bill Lear <rael@zopyra.com> writes:

> ... I did try doing this:
>
> 1) with 1.4.4.1 git, clone my public repo
> 2) in this new clone, make modifications to my files as before
> 3) with 1.5.0 git, do a commit
>
> and I got the same blowup on commit, and this on fsck, with 1.5.0 git:
>
> % git fsck-objects --full
> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
> error: 00078437c23cbc04da52233f4f412219f88b8927: object corrupt or missing
> fatal: unknown object type 5 in .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack

If you stop after cloning but before making a modification, is
the repository in good shape?

> % ls -l objects/pack/
> total 85992
> -r--r--r--  1 blear software    77360 Feb 13 10:18 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
> -r--r--r--  1 blear software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
>
> The .pack files have the same SHA, but different sizes (don't know
> what that means).

That is usually not a problem;  the name reflects the names of
objects contained in the pack (so both have the same set of
objects), but the actual raw contents (and the offsets recorded
in corresponding .idx file) depends on the packing parameters
(window, depth and deltabaseoffset).

Re: Error converting from 1.4.4.1 to 1.5.0?

[Linus Torvalds]

On Wed, 14 Feb 2007, Bill Lear wrote:
> 
> No NFS, but I checked /var/log/messages.  I see segfaults from git,
> that I missed somehow (don't remember seeing anything awry on the
> terminal):
> 
> Feb 14 10:05:07 lisa kernel: git[21648]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
> Feb 14 10:05:43 lisa kernel: git[21710]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
> Feb 14 10:06:28 lisa kernel: git[21858]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
>
> 10:05 is just before I posted my first note of this to the git list, and
> the first instance of a segfault that I see.

Ok, this is almost certainly what's up. For some strange reason your git 
binary segfaults on the clone. The scary thing is, it left your cloned 
repo in a bad state without even telling you. That's not good.  Normally 
we should always die() and give a _reason_ for a failure.

If you have that particular git binary, doing a

	gdb git

and then at the gdb prompt doing

	x/5i 0x0000003f5eb709d0

will at least tell where the SIGSEGV happened, but it doesn't give a 
backtrace so unless it's obvious, it can be a bit hard to debug remotely..

			Linus

Re: Error converting from 1.4.4.1 to 1.5.0?

[Bill Lear]

WAAAAAIAMINIT ... I think I see it:

% perl -pi -e 's/.*\$Id.*//sx' $(xgrep -l '[$]Id')

Could I have corrupted the pack file?  I'll bet $50 I did:

% [yet another clone]
% xgrep -l '[$]Id'
./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
[...]

%!@#$&$%(@@@!!!

I sent this list to a Perl script to nuke CVS Ids!  I invoked this
one level up in my directories, not in my source tree, and .git
got picked up.

[Really, Really Red Shame Face Here]

Ok, I win $50, and I owe each of you a bottle of very good wine for
wasting your time.  Just send me an email privately to tell me what
you prefer ... seriously, very seriously ....

I am, however, still curious about the git segfaults in my
/var/log/messages.


Bill

Re: Error converting from 1.4.4.1 to 1.5.0?

[Junio C Hamano]

Bill Lear <rael@zopyra.com> writes:

> WAAAAAIAMINIT ... I think I see it:
>
> % perl -pi -e 's/.*\$Id.*//sx' $(xgrep -l '[$]Id')
>
> Could I have corrupted the pack file?  I'll bet $50 I did:
>
> % [yet another clone]
> % xgrep -l '[$]Id'
> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
> [...]
>
> %!@#$&$%(@@@!!!

We all make mistakes.  Thanks for being honest.

The segfaults could be from "git commit" codepath, not from when
you cloned.  I could try corrupting a packfile in my repository
and see where it dies, perhaps later.
 

Re: Error converting from 1.4.4.1 to 1.5.0?

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Bill Lear <rael@zopyra.com> writes:
>
>> WAAAAAIAMINIT ... I think I see it:
>>
>> % perl -pi -e 's/.*\$Id.*//sx' $(xgrep -l '[$]Id')
>>
>> Could I have corrupted the pack file?  I'll bet $50 I did:
>>
>> % [yet another clone]
>> % xgrep -l '[$]Id'
>> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
>> [...]
>>
>> %!@#$&$%(@@@!!!
>
> We all make mistakes.  Thanks for being honest.

By the way, I sometimes think it might be worth doing this:

	$ chmod a-r .git/

We always access files by explicit paths and never ask "ls .git/foo*"
to find what are under .git/ directory.

Re: Error converting from 1.4.4.1 to 1.5.0?

[Johannes Schindelin]

Hi,

On Wed, 14 Feb 2007, Bill Lear wrote:

> I sent this list to a Perl script to nuke CVS Ids!  I invoked this one 
> level up in my directories, not in my source tree, and .git got picked 
> up.

Do not be embarassed. Yours truly managed something similar (actually, I 
was running a script to kill all \r from files supposed to be text, and I 
forgot the "*" in `find * -type f`), but _without_ a backup. That was fun.

Ciao,
Dscho

Re: Error converting from 1.4.4.1 to 1.5.0?

[Johannes Schindelin]

Hi,

On Wed, 14 Feb 2007, Junio C Hamano wrote:

> By the way, I sometimes think it might be worth doing this:
> 
> 	$ chmod a-r .git/
> 
> We always access files by explicit paths and never ask "ls .git/foo*" to 
> find what are under .git/ directory.

If so, please make it unconfigurable. I use tab-completion in the git 
directory quite often.

Ciao,
Dscho

Re: Error converting from 1.4.4.1 to 1.5.0?

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Wed, 14 Feb 2007, Junio C Hamano wrote:
>
>> By the way, I sometimes think it might be worth doing this:
>> 
>> 	$ chmod a-r .git/
>> 
>> We always access files by explicit paths and never ask "ls .git/foo*" to 
>> find what are under .git/ directory.
>
> If so, please make it unconfigurable. I use tab-completion in the git 
> directory quite often.

Do you mean "configurable"?

I wonder what you are doing inside .git directory in the first
place.  I never chdir() into it myself, but that may be because
I practicaly live inside Emacs.

Re: Error converting from 1.4.4.1 to 1.5.0?

[Nicolas Pitre]

On Wed, 14 Feb 2007, Bill Lear wrote:

> WAAAAAIAMINIT ... I think I see it:
> 
> % perl -pi -e 's/.*\$Id.*//sx' $(xgrep -l '[$]Id')
> 
> Could I have corrupted the pack file?  I'll bet $50 I did:
> 
> % [yet another clone]
> % xgrep -l '[$]Id'
> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
> [...]
> 
> %!@#$&$%(@@@!!!

But...... your pack file is read-only, isn't it?

Is perl -i so bad to overwrite even read only files?


Nicolas

Re: Error converting from 1.4.4.1 to 1.5.0?

[Johannes Schindelin]

Hi,

On Wed, 14 Feb 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Wed, 14 Feb 2007, Junio C Hamano wrote:
> >
> >> By the way, I sometimes think it might be worth doing this:
> >> 
> >> 	$ chmod a-r .git/
> >> 
> >> We always access files by explicit paths and never ask "ls .git/foo*" to 
> >> find what are under .git/ directory.
> >
> > If so, please make it unconfigurable. I use tab-completion in the git 
> > directory quite often.
> 
> Do you mean "configurable"?

No. I meant "unconfigurable", since the sane default _would_ be a-r.

But then, I see that I was silly. This chmod is done on git-init time, and 
easy to undo _if_ you want it.

So, colour me a supporter of that feature.

> I wonder what you are doing inside .git directory in the first place.  
> I never chdir() into it myself, but that may be because I practicaly 
> live inside Emacs.

:-) Lucky you. Since long time, I became a vi user, not out of fun, but 
out of necessity. I had to work on many machines which had vi installed, 
but not emacs. On some, my quota was not large enough to compile the 
beast, so I eventually gave in.

Back to the subject: Sometimes I just want to look if a certain file is 
present. But I cannot be bothered to really type out ".git/index.lock", 
but rather I do ".g<TAB>/i<TAB>.<TAB>"...

Anyway, here is a minimal (completely untested) patch to do what you 
proposed:

-- snipsnap --

[PATCH] init: create GIT_DIR non-readable

We access all files in GIT_DIR by name, so we do not really need it to be 
readable. However, it is less easy to corrupt the repository 
unintentionally when it is not readable.

Those who want to be able to see the contents of GIT_DIR, always can just 
do a `chown u+r $GIT_DIR`.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

---

 builtin-init-db.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin-init-db.c b/builtin-init-db.c
index 12e43d0..8496269 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -18,7 +18,7 @@
 
 static void safe_create_dir(const char *dir, int share)
 {
-	if (mkdir(dir, 0777) < 0) {
+	if (mkdir(dir, share ? 0777 : 0333) < 0) {
 		if (errno != EEXIST) {
 			perror(dir);
 			exit(1);

Re: Error converting from 1.4.4.1 to 1.5.0?

[Bill Lear]

On Wednesday, February 14, 2007 at 17:27:24 (-0500) Nicolas Pitre writes:
>On Wed, 14 Feb 2007, Bill Lear wrote:
>> %!@#$&$%(@@@!!!
>
>But...... your pack file is read-only, isn't it?

Correct.

>Is perl -i so bad to overwrite even read only files?

It is bad.  Evil.  I will sue Larry Wall for making me, an innocent,
look so foolish.

I'm still muttering to myself that I could be that dumb...


Bill

Re: Error converting from 1.4.4.1 to 1.5.0?

[Linus Torvalds]

On Wed, 14 Feb 2007, Bill Lear wrote:
>
> WAAAAAIAMINIT ... I think I see it:
> 
> % perl -pi -e 's/.*\$Id.*//sx' $(xgrep -l '[$]Id')
> 
> Could I have corrupted the pack file?  I'll bet $50 I did:

Heh.

I'm relieved git is off the hook, although I think we should still look at 
that SIGSEGV. We might well have some situation where we react badly do a 
corrupt pack (most likely, by having one of the object parsing routines 
return NULL, and then we follow that NULL pointer rather than saying "bad 
object").

> % [yet another clone]
> % xgrep -l '[$]Id'
> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack

This is just one reason I don't ever use 'find' on my source tree. I long 
ago used to do

	find . -name '*.c' | xargs grep ...

etc, but especially with git I have almost totally stopped using "xargs 
grep" entirely - to the point where I actually end up importing tar-files 
into new git archives just because I'm so used to "git grep".

So I would suggest that in order to avoid this in the future, you teach 
your fingers to say "git grep" instead of "xgrep"., which I assume is just 
some local alias of yours for "find .. | xargs grep"?

"git grep" really works wonderfully well, and you could have just done

	perl -pi -e 's/.*\$Id.*//sx' $(git grep -l '[$]Id')

instead.

("git grep" is much nicer than "xargs grep" in many other ways too. You 
can ask it to limit itself to a certain pattern of filenames etc by doing

	git grep -l '[$]Id' -- 'net/*.[ch]'

as long as you realize that the name pattern for git grep considers '*' to 
act like '**' does for some shells - ie it globs against '/'too, so the 
above will find any C and header files under the net/ directory, however 
deep they are.. And you can ask it to grep in just a certain revision etc 
too).

Once you get used to "git grep", I bet you'll forget all about "xgrep", 
and won't have to worry about going into the .git/ directory by mistake 
any more.

There are other tricks you can do, but they are somewhat inconvenient. 
They range from making ".git" a symlink to somewhere else (to stop 
"find" from following it), and in your case, since you apparently already 
have an "xgrep" alias for this, you could just teach your "find" thing to 
do something like what we do in the kernel Makefile:

	RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS -o -name .pc -o -name .hg -o -name .git \) -prune -o

and then we use

	find . $(RCS_FIND_IGNORE) ...

which knows to ignore ".git" directories along with all the other 
SCCS/CVS/SVN/BK/etc directories.

		Linus

Re: Error converting from 1.4.4.1 to 1.5.0?

[Linus Torvalds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1011 bytes --]



On Wed, 14 Feb 2007, Nicolas Pitre wrote:
> 
> But...... your pack file is read-only, isn't it?

Almost any "edit in place" operation under UNIX is invariably a question 
of "read old file + write new file + mv new old". 

As such, to be read-only for a lot of programs, you actually need to not 
just make the *file* read-only, you need to make the *directory* read-only 
too. 

Or you need to use only tools that explicitly check (a lot of editors will 
do that, for example, because in an RCS world you're supposed to do magic 
things to actually edit a file).

So I'm not at all surprised that "-pi" (where the "i" stands for 
"in-place") will overwrite read-only files.

I'm sure there is some random character that makes perl check, and not do 
it. Probably a sequence of unusual characters that makes it look like a 
swear-word. 

Maybe "perl -pi -%££@$" will do it. And if not, just add random characters 
until it works. "It's the perl way".

	Linus "Yeah, I never really got the 'perl way'" Torvalds

Re: Error converting from 1.4.4.1 to 1.5.0?

[Jakub Narebski]

Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> On Wed, 14 Feb 2007, Junio C Hamano wrote:
>>
>>> By the way, I sometimes think it might be worth doing this:
>>> 
>>>     $ chmod a-r .git/
>>> 
>>> We always access files by explicit paths and never ask "ls .git/foo*" to 
>>> find what are under .git/ directory.
>>
>> If so, please make it unconfigurable. I use tab-completion in the git 
>> directory quite often.
> 
> Do you mean "configurable"?
> 
> I wonder what you are doing inside .git directory in the first
> place.  I never chdir() into it myself, but that may be because
> I practicaly live inside Emacs.

I look what interesting is in here (like COMMIT_EDITMSG, MERGE_HEAD,
ORIG_HEAD, some StGIT templates,....).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Error converting from 1.4.4.1 to 1.5.0?

[Olivier Galibert]

On Wed, Feb 14, 2007 at 02:13:01PM -0800, Junio C Hamano wrote:
> I wonder what you are doing inside .git directory in the first
> place.  I never chdir() into it myself, but that may be because
> I practicaly live inside Emacs.

"Hmmm, how did I call this remote already? ls .g<TAB>rem<TAB><RET>
ahhh, I see".

Emacs happily does the completion too, but obviously also requires +r
for that.

  OG.

OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)

[Simon 'corecode' Schubert]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

Bill Lear wrote:
> I'm still muttering to myself that I could be that dumb...

Still better than trying to backup with

tar czvf data* destfile.tar.gz

automatic tape backup is a real helper then :)

cheers
  simon

-- 
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: Error converting from 1.4.4.1 to 1.5.0?

[Johannes Schindelin]

Hi,

On Thu, 15 Feb 2007, Olivier Galibert wrote:

> On Wed, Feb 14, 2007 at 02:13:01PM -0800, Junio C Hamano wrote:
> > I wonder what you are doing inside .git directory in the first
> > place.  I never chdir() into it myself, but that may be because
> > I practicaly live inside Emacs.
> 
> "Hmmm, how did I call this remote already? ls .g<TAB>rem<TAB><RET>
> ahhh, I see".

Hmm. That does not work for remotes which are stored in the config (which 
is the default nowadays)...

So, what you described is obviously wrong.

Besides, "git remote" is way shorter. And it even completes if you 
installed the bash completion script!

Ciao,
Dscho

Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)

[Shawn O. Pearce]

Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:
> Bill Lear wrote:
> >I'm still muttering to myself that I could be that dumb...
> 
> Still better than trying to backup with
> 
> tar czvf data* destfile.tar.gz
> 
> automatic tape backup is a real helper then :)

or manual backup to "tape", where the tape device supplied was
the only disk...  SunOS 4 did not take too kindly to its kernel,
swap space, root fs being overwritten...

Oddly enough, that system never booted again.  Ever.  We couldn't
even get it to see external (CD-ROM) based media.  SCSI controller
also failed during the "tape" backup.

-- 
Shawn.

Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)

[Linus Torvalds]

On Wed, 14 Feb 2007, Shawn O. Pearce wrote:

> Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:
> > Bill Lear wrote:
> > >I'm still muttering to myself that I could be that dumb...
> > 
> > Still better than trying to backup with
> > 
> > tar czvf data* destfile.tar.gz
> > 
> > automatic tape backup is a real helper then :)
> 
> or manual backup to "tape", where the tape device supplied was
> the only disk...  SunOS 4 did not take too kindly to its kernel,
> swap space, root fs being overwritten...

Hey, I can beat that (stop me at any time you've heard this story. No? Ok, 
then..)

I auto-dialed my harddisk. 

I had this auto-dialer, that would send "+++" + "atz" + "atdt..." to dial 
the number to the university dial-in farm that was always busy for hours 
at a time, and since I've never been much of a user interface person ("No 
really? Linus, please tell more! I would never have guessed!"), it was 
basically

	autodial /dev/ttyS1

or something very similar. It was really stupid too, so if it got some 
other answer than "BUSY" or "CONNECTED" back (or timed out), it would just 
go on to the next number and try again.

Anyway, the smarter among you will already see how I by mistake filled up 
one of my harddisk partitions with Hayes "AT" modem commands, and deleted 
my Minix installation. AND THE BASTARD NEVER ANSWERED!

That was one big (perhaps _the_) impetus for just deciding to make Linux 
good enough that I wouldn't need to actually reinstall Minix. Happily, it 
was already able to bootstrap itself at that point, it just wasn't quite 
as good yet. I fixed that in short order, and indeed, I never did end up 
feeding the 17 floppy disks into my computer to reinstall Minix.

Moral of the story: "Stupidity is what makes the world go round."

Or something like that.

			Linus

Re: Error converting from 1.4.4.1 to 1.5.0?

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

Bill Lear wrote:
> WAAAAAIAMINIT ... I think I see it:
> 
> % perl -pi -e 's/.*\$Id.*//sx' $(xgrep -l '[$]Id')
> 
> Could I have corrupted the pack file?  I'll bet $50 I did:
> 
> % [yet another clone]
> % xgrep -l '[$]Id'
> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
> [...]
> 
> %!@#$&$%(@@@!!!
I suffered from something like that, too.  Since then I have a script
"ufind".  It's a wrapper around find that ignores CVS, Subversion, Git
and hg metadata.  Then "my" command would be:

	$ ufind -type f -print0 | xargs -0 -r grep -lZ '[$]Id' | xargs -r perl -p -i -e 's/.../'


Where ... is something more restrictive that your .*\$Id.*

For the interessted the script is attached.

-- 
Uwe Kleine-König

cat /*dev/null; echo 'Hello World!';
cat > /dev/null <<*/ 
() { } int main() { printf("Hello World!\n");}
/* */

[-- Attachment #2: ufind --]
[-- Type: text/plain, Size: 477 bytes --]

#! /usr/bin/env python
# Copyright (C) Uwe Zeisberger

import itertools, os, sys

ignoreexpr = ['-type', 'd', '(', '-name', 'CVS', '-o', '-name', '.svn', '-o', '-name', '.git', '-o', '-name', '.hg', ')']
paths = list(itertools.takewhile(lambda x: x[0] not in '-(),!', sys.argv[1:]))

args = sys.argv[1 + len(paths):] or ['-true']

os.execvp('find', ['find'] + paths + ['('] + ignoreexpr + [')', '-prune', '-false', '-o', '-not', '('] + ignoreexpr + [')', '('] + args + [')'])

Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)

[Andy Parkins]

On Thursday 2007 February 15 01:18, Simon 'corecode' Schubert wrote:

> > I'm still muttering to myself that I could be that dumb...

How about this:

1) "I should like to clean up root's home directory"
2) cd /root; ls -la .
3) "Oh, there are a lot of config file in this directory that I don't need any
   more"
4) rm -rf .*

Now start crying softly to yourself, when you realise that ".." is covered 
by ".*".  Now go to every computer you work on and put

  export GLOBIGNORE=".:.."

In your .bashrc.

Boy, was my face red...



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)

[Johannes Schindelin]

Hi,

On Wed, 14 Feb 2007, Linus Torvalds wrote:

> On Wed, 14 Feb 2007, Shawn O. Pearce wrote:
> 
> > Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:
> > > Bill Lear wrote:
> > > >I'm still muttering to myself that I could be that dumb...
> > > 
> > > Still better than trying to backup with
> > > 
> > > tar czvf data* destfile.tar.gz
> > > 
> > > automatic tape backup is a real helper then :)
> > 
> > or manual backup to "tape", where the tape device supplied was
> > the only disk...  SunOS 4 did not take too kindly to its kernel,
> > swap space, root fs being overwritten...
> 
> Hey, I can beat that (stop me at any time you've heard this story. No? 
> Ok, then..)

We're having a dick contest? Well, I'm game.

> I auto-dialed my harddisk. 

I connected a tape drive.

It was a SCSI tape drive, and I had a SCSI Zip drive, which was so often 
connected/disconnected in-flight that the plug wore out. So I thought that 
it should not be a problem to connect the SCSI tape drive to a running 
system. Right? RIGHT?

BIG MISTAKE.

The SCSI adapter also hosted two RAID systems, one as a SCSI RAID, i.e. 
managed by the adapter, and one as ATAPI RAID, i.e. managed by its own 
embedded computer simulating one (actually, two) SCSI hard disks to the 
SCSI adapter.

We wanted to backup some of the data, and that's why we connected the tape 
drive.

First, we got write errors on the RAID. Then, one RAID (the SCSI one) 
stopped working at all. The fans still moved air, but the bus no longer 
moved _any_ bytes.

Panicked (Douglas Adams, where are you when I need you?), I disconnected 
the tape drive, and the two RAID boxes (all of them were external, so 
that was possible). I shut down the computer and let out a long breath of 
hope.

In the course of several weeks, my days started with praying, connecting 
one or both RAIDs to several SCSI adapter/computer pairings, hoping that I 
could read _anything_ from them.

All of the data was lost. Four terabytes. 6-7 months work of three people. 

To this date, the SCSI RAID is not working. After one week (through which 
it did not work _at all_), the ATAPI RAID worked again (strangely enough), 
but had lost the correct order of its 14 disks.

Even if I could reconstruct the correct order after two more weeks, I 
could not get any data from the RAID, since I had nowhere nearly large 
enough amounts of free disk space. And I could not teach the RAID the 
correct order.

And the tape drive still does not work.

Okay, guys, top _that_.

Ciao,
Dscho

Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)

[Bill Lear]

On Wednesday, February 14, 2007 at 18:51:09 (-0800) Linus Torvalds writes:
>On Wed, 14 Feb 2007, Shawn O. Pearce wrote:
>> Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:
>> > Bill Lear wrote:
>> > >I'm still muttering to myself that I could be that dumb...
>> > 
>> > Still better than trying to backup with
>> > 
>> > tar czvf data* destfile.tar.gz
>> > 
>> > automatic tape backup is a real helper then :)
>> 
>> or manual backup to "tape", where the tape device supplied was
>> the only disk...  SunOS 4 did not take too kindly to its kernel,
>> swap space, root fs being overwritten...
>
>Hey, I can beat that (stop me at any time you've heard this story. No? Ok, 
>then..)
>
>I auto-dialed my harddisk. 
>...
>That was one big (perhaps _the_) impetus for just deciding to make Linux 
>good enough that I wouldn't need to actually reinstall Minix. ...
>was already able to bootstrap itself at that point, it just wasn't quite 
>as good yet. I fixed that in short order, and indeed, I never did end up 
>feeding the 17 floppy disks into my computer to reinstall Minix.
>
>Moral of the story: "Stupidity is what makes the world go round."

Agreed.  I often think stupid mistakes are a way of injecting random
--- and at the time, unwelcome --- searches into creative solution
spaces.

As in other cases, this one involved an extremely simple answer very
close to the start of the solution space, but (thanks to me), we drug
this out all over the place and got to explore lots of things we
otherwise wouldn't have.


Bill

Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)

[Michael K. Edwards]

Not quite in the same vein, but perhaps amusing to Silicon Valley veterans:

I worked for several years for a 64-bit processor + workstation vendor
that shall remain nameless.  There was this one guy in the other
building who built the kernels for the 64-bit UNIX variant that
shipped with US models.  He had a SunOS 4 box on his desk that
happened to be the only machine in the world where his magic
32-to-64-bit cross-compiler generated working kernels, for reasons no
one ever fully understood.  The external SCSI died one day, and either
there were no backups or they wouldn't restore cleanly.  I don't think
they ever shipped another kernel update.

I can't swear to the accuracy of that story, though; my mind was on
the million-dollar "high availability" NFS server deployment I was
swept up in.  The vendor never did get the electricals straight on the
shared SCSI bus, possibly because we had shelled out for redundant
power supplies via independent UPSes all the way out to the backup
generator, probably creating a gimongous ground loop.  Kept frying the
third-party SCSI cards that were the key to the whole system, and
scrambled the contents of the terabyte RAID more than once.  I don't
think those backups ever worked, either.  The whole kit got ripped out
after some months of chaos and replaced with in-house gear, which
never worked right either.

Somewhere along the way, I figured out that the whole company (a U.S.
subsidiary of a Japanese multinational) was a clever arbitrage of the
Japanese tax system.  As I understand it, they got tax credits for
foreign direct investment each quarter, then turned around and sent
most of the check back to the parent company to purchase custom DIMMs
at absurd prices, earning yet more tax credits for export in a
critical high-tech product sector.  They made a tidy profit at the
Japanese taxpayers' expense even if we accomplished nothing
whatsoever.

The dedicated chip design and verification team didn't seem to have
cottoned onto this, though, and went through literally dozens of spins
(using the parent's semiconductor manufacturing division, natch).
Their design simulated substantially correctly at the logic level
(nothing you couldn't work around in the compiler) from the beginning,
but actual fabrication exposed problem after problem in the cell
library associated with the parent company's recent process shrink.
(Naturally, the NRE sent back to the parent for each chip spin also
qualified for super-duper tax credits.)

By the time the similar processor division back in Japan went through
the same shrink, the cell library and design rule kinks were all
worked out.  So they got working silicon on the first spin where the
logic was correct (which was not, if I recall correctly, anything
close to the first spin; but they probably weren't charged NRE).
Guess which division took the fall?  Hint: the tax credits expired in
2001, and so did the US subsidiary.  They got another tax credit for
liquidation losses, of course.  Legend at the time had it that the
company had never had a break-even quarter in 11 years of existence,
and had burned more actual cash than any Silicon Valley startup of its
era.  (In retrospect the numbers don't appear to support the latter
claim.)

I got to do some fun stuff while I was there, though, including a
Frankenstein monster of an encrypted CVS transport that slotted SSLeay
into the GSSAPI interface intended for Kerberos.  (Given the choice of
Kerberizing the site or running our own CA for client certs, we picked
the latter.)  Although we had the source to Solaris, UnixWare, and
Windows NT all under one roof, the "secure" version control was not
for any of these.  It was reserved for the real crown-jewels-on-loan:
the source to the OpenBoot PROM.  Go figure.

Cheers,
- Michael

Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)

[Mark Wooding]

Andy Parkins <andyparkins@gmail.com> wrote:

> 4) rm -rf .*

I'm nowhere near that impressive, unfortunately.

Once upon a time, I was trying to build some package (I forget which)
from its source distribution.  It was an GNU-y Autoconf kind of thing.
I didn't want to install it globally at that point, just in my home
directory.  So I said

  $ ./configure --prefix=~
  $ make
  $ make install

So far, so good.  Now try to run the thing.

  $ foo
  bash: foo: command not found

Oh.  Where's it gone?

  $ ls

That's annoying.  Bad shell.  It's failed to expand `~', and just put
everything in a directory called `~' in my build tree.  Bugger.  I don't
want it there.

  $ rm -rf ~

I wonder why it's taking so lo... ^C^C^C^C

-- [mdw]