Torsten Bögershausen [off-list ref] writes:
quoted
quoted
Linux:
error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit
error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links
error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object
Mac OS X:
error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob
error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing
Interesting difference.
quoted
That seems very broken. That sha1 can have only one type, so OS X is
actually mis-parsing the object type? Weird. I would suggest a memory
error or race condition, but the test is valgrind-clean, and fsck should
not be threaded at all.
"is a blob, not a commit" is likely to come from validating of the
tag 66f6581d that presumably point at 63499e4; it reads the tag,
learns the name of the object that is tagged and the type of it,
remembers that the object pointed at (which it hasn't and is going
to validate next) _must_ be a commit (because tag says so) and then
realizes when it reads 63499e4 it is a blob and barfs.
And that is what _should_ happen in that test. It crafts a
malformed tag that points at a blob and claims that it is a commit.
The test makes sure fsck catches that, and it does.
On the other hand, "is a commit, not a blob", unless you have a tag
that directly points at a blob, is more likely to come from
validating some tree object. It reads the tree, learns the name of
the object contained in the tree and infers the type of that object
from the mode bits in the tree (100644 or 100755 would mean the
object must be a blob), goes on to validate that object and realizes
it is a commit and barfs.
It is veriy unusual to get, even on two different platforms, both
messages for the same object.
Could it be that you have i18n on "Object %s is a %s, not a %s" with
a wrong .po file that swaps the latter two parameters in the output?
quoted
What does "git show 63499e4" show when the test has failed?
Was this question ever answered (I would prever "cat-file -t"
followed by "cat-file <type>" instead of "show" for things like
this)? It should show that it is a blob whose contents is "blob\n".
Checking tag 66f6581d549f70e05ca586bc2df5c15a95662c36
Checking commit 134756353796a5439d93586be27999eea3807a34
Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171
error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit,
not a blob
error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing
Checking tree bd04fbdc74c1ad468ee1cc86d49860490ab3e6c7
Checking commit c9145d6720f85544cc4bb6009a2e541660aa156b
Checking tree c9176b0dd1a95c80ad8de21784b1eeffd3681f49
Checking blob f719efd430d52bcfc8566a43b2eb655688d38871
Checking cache tree
Checking connectivity (32 objects)
Checking 63499e4ea8e096b831515ceb1d5a7593e4d87ae5
Checking 66f6581d549f70e05ca586bc2df5c15a95662c36
Checking c9145d6720f85544cc4bb6009a2e541660aa156b
Checking c9176b0dd1a95c80ad8de21784b1eeffd3681f49
Checking 134756353796a5439d93586be27999eea3807a34
Checking 5626abf0f72e58d7a153368ba57db4c673c0e171
Checking f719efd430d52bcfc8566a43b2eb655688d38871
Checking bd04fbdc74c1ad468ee1cc86d49860490ab3e6c7
===========
diff failed passed
diff out ../../../git.next/t/trash_directory.t1450-fsck2_120912_205305/out
17a18,20
quoted
Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171
Checking blob 63499e4ea8e096b831515ceb1d5a7593e4d87ae5
error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit
This is the correct behaviour.
18a22,23
quoted
error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links
error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object
This too.
20,22d24
< Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171
< error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob
< error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing
Thanks Junio,
and all readers
commenst and answers are inline
On 19.09.12 20:30, Junio C Hamano wrote:
Torsten Bögershausen [off-list ref] writes:
quoted
quoted
quoted
Linux:
error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit
error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links
error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object
Mac OS X:
error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob
error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing
Interesting difference.
quoted
quoted
That seems very broken. That sha1 can have only one type, so OS X is
actually mis-parsing the object type? Weird. I would suggest a memory
error or race condition, but the test is valgrind-clean, and fsck should
not be threaded at all.
"is a blob, not a commit" is likely to come from validating of the
tag 66f6581d that presumably point at 63499e4; it reads the tag,
learns the name of the object that is tagged and the type of it,
remembers that the object pointed at (which it hasn't and is going
to validate next) _must_ be a commit (because tag says so) and then
realizes when it reads 63499e4 it is a blob and barfs.
And that is what _should_ happen in that test. It crafts a
malformed tag that points at a blob and claims that it is a commit.
The test makes sure fsck catches that, and it does.
On the other hand, "is a commit, not a blob", unless you have a tag
that directly points at a blob, is more likely to come from
validating some tree object. It reads the tree, learns the name of
the object contained in the tree and infers the type of that object
from the mode bits in the tree (100644 or 100755 would mean the
object must be a blob), goes on to validate that object and realizes
it is a commit and barfs.
Sorry for not knowing better and asking stupid questions.
"Reads the tree", does it mean "read the index file" and put all objects into memory
or does it mean "scan the file system using readdir()"
Or is both done?
It looks as if there is a different execution order (wild speculation)
It is veriy unusual to get, even on two different platforms, both
messages for the same object.
Could it be that you have i18n on "Object %s is a %s, not a %s" with
a wrong .po file that swaps the latter two parameters in the output?
I'm using
LANG=en_US.UTF-8
quoted
quoted
What does "git show 63499e4" show when the test has failed?
Was this question ever answered (I would prever "cat-file -t"
followed by "cat-file <type>" instead of "show" for things like
this)? It should show that it is a blob whose contents is "blob\n".
The question was never answered - I recently learnt that 63499e4 has been removed by this line:
test_when_finished "remove_object $sha" &&
And when I remove that line in the modified test case, I get:
=====================
Mac OS X, failed
--------------
find . -name "499e4*"
./.git/objects/63/499e4ea8e096b831515ceb1d5a7593e4d87ae5
find . -name "499e4*" | xargs xxd
0000000: 7801 4bca c94f 5230 6548 0252 5c00 1938 x.K..OR0eH.R\..8
0000010: 039e ..
git show 63499e4
blob
git cat-file -t 63499e4
blob
git cat-file blob 63499e4
blob
=========================
Mac OS X passed
---------------
~/projects/git/git.next/t/trash_directory.t1450-fsck2_120919_214913> ../../../errors_on_master/1450/junio.sh
find . -name "499e4*"
./.git/objects/63/499e4ea8e096b831515ceb1d5a7593e4d87ae5
find . -name "499e4*" | xargs xxd
0000000: 7801 4bca c94f 5230 6548 0252 5c00 1938 x.K..OR0eH.R\..8
0000010: 039e ..
git show 63499e4
blob
git cat-file -t 63499e4
blob
git cat-file blob 63499e4
blob
==============
Linux failed
----------
find . -name "499e4*"
./.git/objects/63/499e4ea8e096b831515ceb1d5a7593e4d87ae5
find . -name "499e4*" | xargs xxd
0000000: 7801 4bca c94f 5230 6548 0252 5c00 1938 x.K..OR0eH.R\..8
0000010: 039e ..
git show 63499e4
blob
git cat-file -t 63499e4
blob
git cat-file blob 63499e4
blob
==========================
So unless I'm too tired to see, there doesn't seem to be a difference
[snip]
quoted
diff failed passed
diff out ../../../git.next/t/trash_directory.t1450-fsck2_120912_205305/out
17a18,20
quoted
Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171
Checking blob 63499e4ea8e096b831515ceb1d5a7593e4d87ae5
error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit
This is the correct behaviour.
quoted
18a22,23
quoted
error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links
error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object
This too.
quoted
20,22d24
< Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171
< error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob
< error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing
OK, both are correct. But why isn't the "broken links" not detected?
Does fsck stop in one case, but continue in the other?
/Torsten
On 09/19/2012 08:30 PM, Junio C Hamano wrote:
Torsten Bögershausen [off-list ref] writes:
"is a blob, not a commit" is likely to come from validating of the
tag 66f6581d that presumably point at 63499e4; it reads the tag,
learns the name of the object that is tagged and the type of it,
remembers that the object pointed at (which it hasn't and is going
to validate next) _must_ be a commit (because tag says so) and then
realizes when it reads 63499e4 it is a blob and barfs.
And that is what _should_ happen in that test. It crafts a
malformed tag that points at a blob and claims that it is a commit.
The test makes sure fsck catches that, and it does.
On the other hand, "is a commit, not a blob", unless you have a tag
that directly points at a blob, is more likely to come from
validating some tree object. It reads the tree, learns the name of
the object contained in the tree and infers the type of that object
from the mode bits in the tree (100644 or 100755 would mean the
object must be a blob), goes on to validate that object and realizes
it is a commit and barfs.
The good news:
With help of Junio's comments I probably found the reason why the test
behaves differently:
The objects are checked in a certain order, based on the inode number.
Which seems to be the same on most machines: when files are created
in a certain order, then the inode numbers are in the same order.
When the inode numbering changes for reasons known to the file system,
the order changes and fsck takes a different code path.
To provoke the error, the following helped at my Linux box:
diff --git a/builtin/fsck.c b/builtin/fsck.c
index a710227..bba8082 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -373,7 +373,7 @@ static struct {
static int ino_compare(const void *_a, const void *_b)
{
- const struct sha1_entry *a = _a, *b = _b;
+ const struct sha1_entry *a = _b, *b = _a;
unsigned long ino1 = a->ino, ino2 = b->ino;
return ino1 < ino2 ? -1 : ino1 > ino2 ? 1 : 0;
}
The bad news: I haven't found the time to prepare a fix.
/Torsten