threads / discuss / 60039

fsck: various diagnostics never triggering

Subject: fsck: various diagnostics never triggering

## tl;dr

One message between Jul 29, 2023 and Jul 29, 2023.

replies: 0people: 1as markdown or json

Xavier Morel· Jul 29, 2023, 16:17 UTC · lore

First I'd like to thank John Cai for the work of collating the fsck msg-id, figuring out what to look for is much easier when it's all in one place.

While looking at git's handling of invalid objects (again) I found out that several documented fsck diagnostics can not fire — and furthermore have somewhat debatable diag levels — because they trigger a parsing error upstream from the fsck code which actually checks the relevant properties.

Some of them are actually present in t/t1451-fsck-buffer.sh but I'm not sure if that is relevant in any way.

The testing / checking was done with Git 2.41.
------
    emptyName (WARN) A path contains an empty name.

`fsck_tree` ultimately calls `decode_tree_entry` which fails (returns -1) if the mode is invalid (e.g. the mode is immediately followed by \0) or the path is empty. In fsck_tree, this translates to a generic `badTree` error.

Also not sure how relevant that is, but a badTree error yields a lot of spam e.g. when specifically fsck-ing the broken tree I get:

    error: empty filename in tree entry
    error in tree {oid}: broken links
    error: empty filename in tree entry
    error in tree {oid}: badTree: cannot be parsed as a tree
    error: empty filename in tree entry

but for the specific error message, this reproduces for every error which results in a "badTree" (mode is empty, mode is invalid, oid is too short, oid is too long, tree object is too short).

It's possible that part of it is an artefact of my test setup e.g. I get this if I fsck the object specifically (passing its oid to "git fsck"), asking fsck to check the repository rather than the specific object seems to remove the last message in the sequence.

    missingTree (ERROR) Missing tree line in a commit object.

If a commit has no `tree` line, or a `tree` line which is not 45 bytes long (excluding newline), fsck reports

     error: bogus commit object {oid}
     error: {oid}: object could not be parsed: {path}
     error: {oid}: object missing
but no missingTree.
    badTreeSha1 (ERROR) A tree has an invalid format.

If a commit has a tree line which is 45 bytes long, but the last 40 bytes are not a valid hex string, fsck reports

     error: bad tree pointer in commit {oid}
     error: {oid}: object could not be parsed: {path}
     error: {oid}: object missing
    badParentSha1 (ERROR) A commit object has a bad parent sha1.
Here whether the parent line is too short, too long, or not hex, fsck reports
    error: bad parents in commit {oid}
    error: {oid}: object could not be parsed: {oid}
    error: {oid}: object missing
-------
Finally at least one diagnostic seems to have an incomplete documentation:
    fullPathname (WARN) A path contains the full path starting with "/"

but the code uses "strchr" on the name, so it checks if the name contains a "/" anywhere. The message is also not the best:

> contains full pathnames
-------
There is also a minor inconsistency in the authorship date parsing:
    0+0000
triggers "zeroPaddedDate", but 
    1+0000
triggers "badDate".

I assume that is because the code first checks if the date is a 0 followed by a non-space (assuming it's zero-padded), and only after that does it check if the timestamp is followed by a space.

This is probably too minor an issue to bother complexifying the checker though.

← back to recent threads