Thanks Junio, and all readers commenst and answers are inline On 19.09.12 20:30, Junio C Hamano wrote: > Torsten Bögershausen <tboegi@xxxxxx> writes: > >>>> 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. > >>> 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 > >>> 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] >> >> diff failed passed >> diff out ../../../git.next/t/trash_directory.t1450-fsck2_120912_205305/out >> 17a18,20 >>> Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171 >>> Checking blob 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 >>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit > > This is the correct behaviour. > >> 18a22,23 >>> 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 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html