fsck: various diagnostics never triggering
- From
- Xavier Morel <xavier.morel@masklinn.net>
- Date
- Jul 29, 2023, 16:17 UTC
- Message-ID
- <305BF2BA-6F33-4C34-8E2F-DB194AC38C2C@masklinn.net>
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 entrybut 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 missingbut 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 missingbadParentSha1 (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.