2007-07-14 23:14:45 +00:00
|
|
|
#include "builtin.h"
|
2023-03-21 06:25:54 +00:00
|
|
|
#include "gettext.h"
|
2023-02-24 00:09:27 +00:00
|
|
|
#include "hex.h"
|
2018-03-23 17:20:57 +00:00
|
|
|
#include "repository.h"
|
2017-06-14 18:07:36 +00:00
|
|
|
#include "config.h"
|
2005-04-18 18:39:48 +00:00
|
|
|
#include "commit.h"
|
|
|
|
#include "tree.h"
|
|
|
|
#include "blob.h"
|
2005-04-28 14:46:33 +00:00
|
|
|
#include "tag.h"
|
2005-07-03 17:01:38 +00:00
|
|
|
#include "refs.h"
|
2005-06-29 09:51:27 +00:00
|
|
|
#include "pack.h"
|
2006-04-25 23:37:08 +00:00
|
|
|
#include "cache-tree.h"
|
2006-05-29 19:19:02 +00:00
|
|
|
#include "tree-walk.h"
|
2008-02-25 21:46:05 +00:00
|
|
|
#include "fsck.h"
|
2007-10-15 20:34:05 +00:00
|
|
|
#include "parse-options.h"
|
2011-11-07 02:59:26 +00:00
|
|
|
#include "progress.h"
|
2012-03-07 10:54:20 +00:00
|
|
|
#include "streaming.h"
|
2017-08-18 22:20:19 +00:00
|
|
|
#include "packfile.h"
|
2023-04-11 07:41:53 +00:00
|
|
|
#include "object-file.h"
|
2023-04-11 07:41:49 +00:00
|
|
|
#include "object-name.h"
|
2023-05-16 06:34:06 +00:00
|
|
|
#include "object-store-ll.h"
|
2023-05-16 06:33:59 +00:00
|
|
|
#include "path.h"
|
2023-05-16 06:33:56 +00:00
|
|
|
#include "read-cache-ll.h"
|
2023-02-24 00:09:33 +00:00
|
|
|
#include "replace-object.h"
|
2022-06-09 23:44:20 +00:00
|
|
|
#include "resolve-undo.h"
|
2018-06-27 13:24:43 +00:00
|
|
|
#include "run-command.h"
|
2023-05-16 06:33:51 +00:00
|
|
|
#include "sparse-index.h"
|
2018-10-21 08:08:58 +00:00
|
|
|
#include "worktree.h"
|
2023-04-17 16:21:38 +00:00
|
|
|
#include "pack-revindex.h"
|
fsck: verify checksums of all .bitmap files
If a filesystem-level corruption occurs in a .bitmap file, Git can react
poorly. This could take the form of a run-time error due to failing to
parse an EWAH bitmap or be more subtle such as returning the wrong set
of objects to a fetch or clone.
A natural first response to either of these kinds of errors is to run
'git fsck' to see if any files are corrupt. This currently ignores all
.bitmap files.
Add checks to 'git fsck' for all .bitmap files that are currently
associated with a multi-pack-index or pack file. Verify their checksums
using the hashfile API.
We iterate through all multi-pack-indexes and pack-files to be sure to
check all .bitmap files, not just the one that would be read by the
process. For example, a multi-pack-index bitmap overrules a pack-bitmap.
However, if the multi-pack-index is removed, the pack-bitmap may be
selected instead. Be thorough to include every file that could become
active in such a way. This includes checking files in alternates.
There is potential that we could extend this effort to check the
structure of the reachability bitmaps themselves, but it is very
expensive to do so. At minimum, it's as expensive as generating the
bitmaps in the first place, and that's assuming that we don't use the
trivial algorithm of verifying each bitmap individually. The trivial
algorithm will result in quadratic behavior (number of objects times
number of bitmapped commits) while the bitmap building operation
constructs a lattice of commits to build bitmaps incrementally and then
generate the final bitmaps from a subset of those commits.
If we were to extend 'git fsck' to check .bitmap file contents more
closely like this, then we would likely want to hide it behind an option
that signals the user is more willing to do expensive operations such as
this.
For testing, set up a repository with a pack-bitmap _and_ a
multi-pack-index bitmap. This requires some file movement to avoid
deleting the pack-bitmap during the repack that creates the
multi-pack-index bitmap. We can then verify that 'git fsck' is checking
all files, not just the "active" bitmap.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-02 13:27:21 +00:00
|
|
|
#include "pack-bitmap.h"
|
2005-04-18 18:39:48 +00:00
|
|
|
|
|
|
|
#define REACHABLE 0x0001
|
2006-05-29 19:18:33 +00:00
|
|
|
#define SEEN 0x0002
|
2013-06-05 22:37:39 +00:00
|
|
|
#define HAS_OBJ 0x0004
|
2017-07-20 00:21:44 +00:00
|
|
|
/* This flag is set if something points to this object. */
|
|
|
|
#define USED 0x0008
|
2005-04-13 16:57:30 +00:00
|
|
|
|
2006-08-15 17:23:48 +00:00
|
|
|
static int show_root;
|
|
|
|
static int show_tags;
|
|
|
|
static int show_unreachable;
|
2007-04-04 14:46:14 +00:00
|
|
|
static int include_reflogs = 1;
|
2009-10-20 18:46:55 +00:00
|
|
|
static int check_full = 1;
|
2015-06-22 15:27:12 +00:00
|
|
|
static int connectivity_only;
|
2006-08-15 17:23:48 +00:00
|
|
|
static int check_strict;
|
|
|
|
static int keep_cache_objects;
|
2015-06-22 15:25:00 +00:00
|
|
|
static struct fsck_options fsck_walk_options = FSCK_OPTIONS_DEFAULT;
|
|
|
|
static struct fsck_options fsck_obj_options = FSCK_OPTIONS_DEFAULT;
|
2007-03-05 08:22:06 +00:00
|
|
|
static int errors_found;
|
2007-07-03 00:33:54 +00:00
|
|
|
static int write_lost_and_found;
|
2007-06-05 02:44:00 +00:00
|
|
|
static int verbose;
|
2011-11-07 02:59:26 +00:00
|
|
|
static int show_progress = -1;
|
2012-02-28 22:55:39 +00:00
|
|
|
static int show_dangling = 1;
|
2016-07-17 11:00:02 +00:00
|
|
|
static int name_objects;
|
2007-03-05 08:22:06 +00:00
|
|
|
#define ERROR_OBJECT 01
|
|
|
|
#define ERROR_REACHABLE 02
|
2011-11-07 02:59:23 +00:00
|
|
|
#define ERROR_PACK 04
|
2015-09-23 20:46:39 +00:00
|
|
|
#define ERROR_REFS 010
|
2018-06-27 13:24:43 +00:00
|
|
|
#define ERROR_COMMIT_GRAPH 020
|
2020-05-19 19:48:45 +00:00
|
|
|
#define ERROR_MULTI_PACK_INDEX 040
|
2023-04-17 16:21:38 +00:00
|
|
|
#define ERROR_PACK_REV_INDEX 0100
|
fsck: verify checksums of all .bitmap files
If a filesystem-level corruption occurs in a .bitmap file, Git can react
poorly. This could take the form of a run-time error due to failing to
parse an EWAH bitmap or be more subtle such as returning the wrong set
of objects to a fetch or clone.
A natural first response to either of these kinds of errors is to run
'git fsck' to see if any files are corrupt. This currently ignores all
.bitmap files.
Add checks to 'git fsck' for all .bitmap files that are currently
associated with a multi-pack-index or pack file. Verify their checksums
using the hashfile API.
We iterate through all multi-pack-indexes and pack-files to be sure to
check all .bitmap files, not just the one that would be read by the
process. For example, a multi-pack-index bitmap overrules a pack-bitmap.
However, if the multi-pack-index is removed, the pack-bitmap may be
selected instead. Be thorough to include every file that could become
active in such a way. This includes checking files in alternates.
There is potential that we could extend this effort to check the
structure of the reachability bitmaps themselves, but it is very
expensive to do so. At minimum, it's as expensive as generating the
bitmaps in the first place, and that's assuming that we don't use the
trivial algorithm of verifying each bitmap individually. The trivial
algorithm will result in quadratic behavior (number of objects times
number of bitmapped commits) while the bitmap building operation
constructs a lattice of commits to build bitmaps incrementally and then
generate the final bitmaps from a subset of those commits.
If we were to extend 'git fsck' to check .bitmap file contents more
closely like this, then we would likely want to hide it behind an option
that signals the user is more willing to do expensive operations such as
this.
For testing, set up a repository with a pack-bitmap _and_ a
multi-pack-index bitmap. This requires some file movement to avoid
deleting the pack-bitmap during the repack that creates the
multi-pack-index bitmap. We can then verify that 'git fsck' is checking
all files, not just the "active" bitmap.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-02 13:27:21 +00:00
|
|
|
#define ERROR_BITMAP 0200
|
2005-04-13 16:57:30 +00:00
|
|
|
|
2019-10-18 04:58:07 +00:00
|
|
|
static const char *describe_object(const struct object_id *oid)
|
2016-07-17 10:59:44 +00:00
|
|
|
{
|
2019-10-18 04:58:07 +00:00
|
|
|
return fsck_describe_object(&fsck_walk_options, oid);
|
2016-07-17 10:59:44 +00:00
|
|
|
}
|
|
|
|
|
2019-10-18 04:58:07 +00:00
|
|
|
static const char *printable_type(const struct object_id *oid,
|
|
|
|
enum object_type type)
|
2017-01-26 04:11:00 +00:00
|
|
|
{
|
|
|
|
const char *ret;
|
|
|
|
|
2019-10-18 04:58:07 +00:00
|
|
|
if (type == OBJ_NONE)
|
|
|
|
type = oid_object_info(the_repository, oid, NULL);
|
fsck: lazily load types under --connectivity-only
The recent fixes to "fsck --connectivity-only" load all of
the objects with their correct types. This keeps the
connectivity-only code path close to the regular one, but it
also introduces some unnecessary inefficiency. While getting
the type of an object is cheap compared to actually opening
and parsing the object (as the non-connectivity-only case
would do), it's still not free.
For reachable non-blob objects, we end up having to parse
them later anyway (to see what they point to), making our
type lookup here redundant.
For unreachable objects, we might never hit them at all in
the reachability traversal, making the lookup completely
wasted. And in some cases, we might have quite a few
unreachable objects (e.g., when alternates are used for
shared object storage between repositories, it's normal for
there to be objects reachable from other repositories but
not the one running fsck).
The comment in mark_object_for_connectivity() claims two
benefits to getting the type up front:
1. We need to know the types during fsck_walk(). (And not
explicitly mentioned, but we also need them when
printing the types of broken or dangling commits).
We can address this by lazy-loading the types as
necessary. Most objects never need this lazy-load at
all, because they fall into one of these categories:
a. Reachable from our tips, and are coerced into the
correct type as we traverse (e.g., a parent link
will call lookup_commit(), which converts OBJ_NONE
to OBJ_COMMIT).
b. Unreachable, but not at the tip of a chunk of
unreachable history. We only mention the tips as
"dangling", so an unreachable commit which links
to hundreds of other objects needs only report the
type of the tip commit.
2. It serves as a cross-check that the coercion in (1a) is
correct (i.e., we'll complain about a parent link that
points to a blob). But we get most of this for free
already, because right after coercing, we'll parse any
non-blob objects. So we'd notice then if we expected a
commit and got a blob.
The one exception is when we expect a blob, in which
case we never actually read the object contents.
So this is a slight weakening, but given that the whole
point of --connectivity-only is to sacrifice some data
integrity checks for speed, this seems like an
acceptable tradeoff.
Here are before and after timings for an extreme case with
~5M reachable objects and another ~12M unreachable (it's the
torvalds/linux repository on GitHub, connected to shared
storage for all of the other kernel forks):
[before]
$ time git fsck --no-dangling --connectivity-only
real 3m4.323s
user 1m25.121s
sys 1m38.710s
[after]
$ time git fsck --no-dangling --connectivity-only
real 0m51.497s
user 0m49.575s
sys 0m1.776s
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-26 04:12:07 +00:00
|
|
|
|
2019-10-18 04:58:07 +00:00
|
|
|
ret = type_name(type);
|
2017-01-26 04:11:00 +00:00
|
|
|
if (!ret)
|
2018-11-10 05:16:15 +00:00
|
|
|
ret = _("unknown");
|
2017-01-26 04:11:00 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-06-22 15:25:09 +00:00
|
|
|
static int objerror(struct object *obj, const char *err)
|
2005-09-20 18:56:05 +00:00
|
|
|
{
|
2007-03-05 08:22:06 +00:00
|
|
|
errors_found |= ERROR_OBJECT;
|
2018-11-10 05:16:15 +00:00
|
|
|
/* TRANSLATORS: e.g. error in tree 01bfda: <more explanation> */
|
|
|
|
fprintf_ln(stderr, _("error in %s %s: %s"),
|
2019-10-18 04:58:07 +00:00
|
|
|
printable_type(&obj->oid, obj->type),
|
|
|
|
describe_object(&obj->oid), err);
|
2005-09-20 18:56:05 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2023-07-03 06:44:18 +00:00
|
|
|
static int fsck_error_func(struct fsck_options *o UNUSED,
|
2019-10-18 04:58:40 +00:00
|
|
|
const struct object_id *oid,
|
|
|
|
enum object_type object_type,
|
2021-03-28 13:15:46 +00:00
|
|
|
enum fsck_msg_type msg_type,
|
2023-07-03 06:44:18 +00:00
|
|
|
enum fsck_msg_id msg_id UNUSED,
|
2021-03-28 13:15:46 +00:00
|
|
|
const char *message)
|
2005-09-20 18:56:05 +00:00
|
|
|
{
|
2019-10-18 04:58:40 +00:00
|
|
|
switch (msg_type) {
|
2018-11-10 05:16:14 +00:00
|
|
|
case FSCK_WARN:
|
2018-11-10 05:16:15 +00:00
|
|
|
/* TRANSLATORS: e.g. warning in tree 01bfda: <more explanation> */
|
|
|
|
fprintf_ln(stderr, _("warning in %s %s: %s"),
|
2019-10-18 04:58:40 +00:00
|
|
|
printable_type(oid, object_type),
|
|
|
|
describe_object(oid), message);
|
2018-11-10 05:16:14 +00:00
|
|
|
return 0;
|
|
|
|
case FSCK_ERROR:
|
2018-11-10 05:16:15 +00:00
|
|
|
/* TRANSLATORS: e.g. error in tree 01bfda: <more explanation> */
|
|
|
|
fprintf_ln(stderr, _("error in %s %s: %s"),
|
2019-10-18 04:58:40 +00:00
|
|
|
printable_type(oid, object_type),
|
|
|
|
describe_object(oid), message);
|
2018-11-10 05:16:14 +00:00
|
|
|
return 1;
|
|
|
|
default:
|
2019-10-18 04:58:40 +00:00
|
|
|
BUG("%d (FSCK_IGNORE?) should never trigger this callback",
|
|
|
|
msg_type);
|
2018-11-10 05:16:14 +00:00
|
|
|
}
|
2005-09-20 18:56:05 +00:00
|
|
|
}
|
|
|
|
|
2008-12-11 03:44:37 +00:00
|
|
|
static struct object_array pending;
|
|
|
|
|
2021-06-01 00:05:59 +00:00
|
|
|
static int mark_object(struct object *obj, enum object_type type,
|
2023-07-03 06:44:18 +00:00
|
|
|
void *data, struct fsck_options *options UNUSED)
|
2008-02-25 21:46:05 +00:00
|
|
|
{
|
|
|
|
struct object *parent = data;
|
|
|
|
|
2011-01-26 20:46:55 +00:00
|
|
|
/*
|
|
|
|
* The only case data is NULL or type is OBJ_ANY is when
|
|
|
|
* mark_object_reachable() calls us. All the callers of
|
|
|
|
* that function has non-NULL obj hence ...
|
|
|
|
*/
|
2008-02-25 21:46:05 +00:00
|
|
|
if (!obj) {
|
2011-01-26 20:46:55 +00:00
|
|
|
/* ... these references to parent->fld are safe here */
|
2018-11-10 05:16:15 +00:00
|
|
|
printf_ln(_("broken link from %7s %s"),
|
2019-10-18 04:58:07 +00:00
|
|
|
printable_type(&parent->oid, parent->type),
|
|
|
|
describe_object(&parent->oid));
|
2018-11-10 05:16:15 +00:00
|
|
|
printf_ln(_("broken link from %7s %s"),
|
|
|
|
(type == OBJ_ANY ? _("unknown") : type_name(type)),
|
|
|
|
_("unknown"));
|
2008-02-25 21:46:05 +00:00
|
|
|
errors_found |= ERROR_REACHABLE;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type != OBJ_ANY && obj->type != type)
|
2011-01-26 20:46:55 +00:00
|
|
|
/* ... and the reference to parent is safe here */
|
2018-11-10 05:16:15 +00:00
|
|
|
objerror(parent, _("wrong object type in link"));
|
2008-02-25 21:46:05 +00:00
|
|
|
|
|
|
|
if (obj->flags & REACHABLE)
|
|
|
|
return 0;
|
|
|
|
obj->flags |= REACHABLE;
|
2017-12-05 16:58:46 +00:00
|
|
|
|
|
|
|
if (is_promisor_object(&obj->oid))
|
|
|
|
/*
|
|
|
|
* Further recursion does not need to be performed on this
|
|
|
|
* object since it is a promisor object (so it does not need to
|
|
|
|
* be added to "pending").
|
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
|
2013-06-05 22:37:39 +00:00
|
|
|
if (!(obj->flags & HAS_OBJ)) {
|
2020-08-05 23:06:52 +00:00
|
|
|
if (parent && !has_object(the_repository, &obj->oid, 1)) {
|
2018-11-10 05:16:15 +00:00
|
|
|
printf_ln(_("broken link from %7s %s\n"
|
|
|
|
" to %7s %s"),
|
2019-10-18 04:58:07 +00:00
|
|
|
printable_type(&parent->oid, parent->type),
|
|
|
|
describe_object(&parent->oid),
|
|
|
|
printable_type(&obj->oid, obj->type),
|
|
|
|
describe_object(&obj->oid));
|
2008-02-25 21:46:05 +00:00
|
|
|
errors_found |= ERROR_REACHABLE;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2013-05-25 09:08:11 +00:00
|
|
|
add_object_array(obj, NULL, &pending);
|
2008-12-11 03:44:37 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mark_object_reachable(struct object *obj)
|
|
|
|
{
|
2015-06-22 15:25:00 +00:00
|
|
|
mark_object(obj, OBJ_ANY, NULL, NULL);
|
2008-12-11 03:44:37 +00:00
|
|
|
}
|
|
|
|
|
2011-01-26 20:46:55 +00:00
|
|
|
static int traverse_one_object(struct object *obj)
|
2008-12-11 03:44:37 +00:00
|
|
|
{
|
2018-01-20 07:43:51 +00:00
|
|
|
int result = fsck_walk(obj, obj, &fsck_walk_options);
|
|
|
|
|
|
|
|
if (obj->type == OBJ_TREE) {
|
|
|
|
struct tree *tree = (struct tree *)obj;
|
|
|
|
free_tree_buffer(tree);
|
|
|
|
}
|
|
|
|
return result;
|
2008-02-25 21:46:05 +00:00
|
|
|
}
|
|
|
|
|
2008-12-11 03:44:37 +00:00
|
|
|
static int traverse_reachable(void)
|
2008-02-25 21:46:05 +00:00
|
|
|
{
|
2011-11-07 02:59:26 +00:00
|
|
|
struct progress *progress = NULL;
|
|
|
|
unsigned int nr = 0;
|
2008-12-11 03:44:37 +00:00
|
|
|
int result = 0;
|
2011-11-07 02:59:26 +00:00
|
|
|
if (show_progress)
|
progress: simplify "delayed" progress API
We used to expose the full power of the delayed progress API to the
callers, so that they can specify, not just the message to show and
expected total amount of work that is used to compute the percentage
of work performed so far, the percent-threshold parameter P and the
delay-seconds parameter N. The progress meter starts to show at N
seconds into the operation only if we have not yet completed P per-cent
of the total work.
Most callers used either (0%, 2s) or (50%, 1s) as (P, N), but there
are oddballs that chose more random-looking values like 95%.
For a smoother workload, (50%, 1s) would allow us to start showing
the progress meter earlier than (0%, 2s), while keeping the chance
of not showing progress meter for long running operation the same as
the latter. For a task that would take 2s or more to complete, it
is likely that less than half of it would complete within the first
second, if the workload is smooth. But for a spiky workload whose
earlier part is easier, such a setting is likely to fail to show the
progress meter entirely and (0%, 2s) is more appropriate.
But that is merely a theory. Realistically, it is of dubious value
to ask each codepath to carefully consider smoothness of their
workload and specify their own setting by passing two extra
parameters. Let's simplify the API by dropping both parameters and
have everybody use (0%, 2s).
Oh, by the way, the percent-threshold parameter and the structure
member were consistently misspelled, which also is now fixed ;-)
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19 17:39:41 +00:00
|
|
|
progress = start_delayed_progress(_("Checking connectivity"), 0);
|
2008-12-11 03:44:37 +00:00
|
|
|
while (pending.nr) {
|
object_array: add and use `object_array_pop()`
In a couple of places, we pop objects off an object array `foo` by
decreasing `foo.nr`. We access `foo.nr` in many places, but most if not
all other times we do so read-only, e.g., as we iterate over the array.
But when we change `foo.nr` behind the array's back, it feels a bit
nasty and looks like it might leak memory.
Leaks happen if the popped element has an allocated `name` or `path`.
At the moment, that is not the case. Still, 1) the object array might
gain more fields that want to be freed, 2) a code path where we pop
might start using names or paths, 3) one of these code paths might be
copied to somewhere where we do, and 4) using a dedicated function for
popping is conceptually cleaner.
Introduce and use `object_array_pop()` instead. Release memory in the
new function. Document that popping an object leaves the associated
elements in limbo.
The converted places were identified by grepping for "\.nr\>" and
looking for "--".
Make the new function return NULL on an empty array. This is consistent
with `pop_commit()` and allows the following:
while ((o = object_array_pop(&foo)) != NULL) {
// do something
}
But as noted above, we don't need to go out of our way to avoid reading
`foo.nr`. This is probably more readable:
while (foo.nr) {
... o = object_array_pop(&foo);
// do something
}
The name of `object_array_pop()` does not quite align with
`add_object_array()`. That is unfortunate. On the other hand, it matches
`object_array_clear()`. Arguably it's `add_...` that is the odd one out,
since it reads like it's used to "add" an "object array". For that
reason, side with `object_array_clear()`.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22 23:34:53 +00:00
|
|
|
result |= traverse_one_object(object_array_pop(&pending));
|
2011-11-07 02:59:26 +00:00
|
|
|
display_progress(progress, ++nr);
|
2008-12-11 03:44:37 +00:00
|
|
|
}
|
2011-11-07 02:59:26 +00:00
|
|
|
stop_progress(&progress);
|
2008-12-11 03:44:37 +00:00
|
|
|
return !!result;
|
2008-02-25 21:46:05 +00:00
|
|
|
}
|
|
|
|
|
fsck: use enum object_type for fsck_walk callback
We switched the function interface for fsck callbacks in a1aad71601
(fsck.h: use "enum object_type" instead of "int", 2021-03-28). However,
we accidentally flipped the type back to "int" as part of 0b4e9013f1
(fsck: mark unused parameters in various fsck callbacks, 2023-07-03).
The mistake happened because that commit was written before a1aad71601
and rebased forward, and I screwed up while resolving the conflict.
Curiously, the compiler does not warn about this mismatch, at least not
when using gcc and clang on Linux (nor in any of our CI environments).
Based on 28abf260a5 (builtin/fsck.c: don't conflate "int" and "enum" in
callback, 2021-06-01), I'd guess that this would cause the AIX xlc
compiler to complain. I noticed because clang-18's UBSan now identifies
mis-matched function calls at runtime, and does complain of this case
when running the test suite.
I'm not entirely clear on whether this mismatch is a problem in
practice. Compilers are certainly free to make enums smaller than "int"
if they don't need the bits, but I suspect that they have to promote
back to int for function calls (though I didn't dig in the standard, and
I won't be surprised if I'm simply wrong and the real-world impact would
depend on the ABI).
Regardless, switching it back to enum is obviously the right thing to do
here; the switch to "int" was simply a mistake.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-08-19 23:53:42 +00:00
|
|
|
static int mark_used(struct object *obj, enum object_type type UNUSED,
|
2023-07-03 06:44:18 +00:00
|
|
|
void *data UNUSED, struct fsck_options *options UNUSED)
|
2008-02-25 21:46:05 +00:00
|
|
|
{
|
|
|
|
if (!obj)
|
|
|
|
return 1;
|
2017-07-20 00:21:44 +00:00
|
|
|
obj->flags |= USED;
|
2008-02-25 21:46:05 +00:00
|
|
|
return 0;
|
2005-09-20 18:56:05 +00:00
|
|
|
}
|
|
|
|
|
fsck: always compute USED flags for unreachable objects
The --connectivity-only option avoids opening every object, and instead
just marks reachable objects with a flag and compares this to the set
of all objects. This strategy is discussed in more detail in 3e3f8bd608
(fsck: prepare dummy objects for --connectivity-check, 2017-01-17).
This means that we report _every_ unreachable object as dangling.
Whereas in a full fsck, we'd have actually opened and parsed each of
those unreachable objects, marking their child objects with the USED
flag, to mean "this was mentioned by another object". And thus we can
report only the tip of an unreachable segment of the object graph as
dangling.
You can see this difference with a trivial example:
tree=$(git hash-object -t tree -w /dev/null)
one=$(echo one | git commit-tree $tree)
two=$(echo two | git commit-tree -p $one $tree)
Running `git fsck` will report only $two as dangling, but with
--connectivity-only, both commits (and the tree) are reported. Likewise,
using --lost-found would write all three objects.
We can make --connectivity-only work like the normal case by taking a
separate pass over the unreachable objects, parsing them and marking
objects they refer to as USED. That still avoids parsing any blobs,
though we do pay the cost to access any unreachable commits and trees
(which may or may not be noticeable, depending on how many you have).
If neither --dangling nor --lost-found is in effect, then we can skip
this step entirely, just like we do now. That makes "--connectivity-only
--no-dangling" just as fast as the current "--connectivity-only". I.e.,
we do the correct thing always, but you can still tweak the options to
make it faster if you don't care about dangling objects.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-05 04:47:39 +00:00
|
|
|
static void mark_unreachable_referents(const struct object_id *oid)
|
|
|
|
{
|
|
|
|
struct fsck_options options = FSCK_OPTIONS_DEFAULT;
|
2019-06-20 07:41:14 +00:00
|
|
|
struct object *obj = lookup_object(the_repository, oid);
|
fsck: always compute USED flags for unreachable objects
The --connectivity-only option avoids opening every object, and instead
just marks reachable objects with a flag and compares this to the set
of all objects. This strategy is discussed in more detail in 3e3f8bd608
(fsck: prepare dummy objects for --connectivity-check, 2017-01-17).
This means that we report _every_ unreachable object as dangling.
Whereas in a full fsck, we'd have actually opened and parsed each of
those unreachable objects, marking their child objects with the USED
flag, to mean "this was mentioned by another object". And thus we can
report only the tip of an unreachable segment of the object graph as
dangling.
You can see this difference with a trivial example:
tree=$(git hash-object -t tree -w /dev/null)
one=$(echo one | git commit-tree $tree)
two=$(echo two | git commit-tree -p $one $tree)
Running `git fsck` will report only $two as dangling, but with
--connectivity-only, both commits (and the tree) are reported. Likewise,
using --lost-found would write all three objects.
We can make --connectivity-only work like the normal case by taking a
separate pass over the unreachable objects, parsing them and marking
objects they refer to as USED. That still avoids parsing any blobs,
though we do pay the cost to access any unreachable commits and trees
(which may or may not be noticeable, depending on how many you have).
If neither --dangling nor --lost-found is in effect, then we can skip
this step entirely, just like we do now. That makes "--connectivity-only
--no-dangling" just as fast as the current "--connectivity-only". I.e.,
we do the correct thing always, but you can still tweak the options to
make it faster if you don't care about dangling objects.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-05 04:47:39 +00:00
|
|
|
|
|
|
|
if (!obj || !(obj->flags & HAS_OBJ))
|
|
|
|
return; /* not part of our original set */
|
|
|
|
if (obj->flags & REACHABLE)
|
|
|
|
return; /* reachable objects already traversed */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid passing OBJ_NONE to fsck_walk, which will parse the object
|
|
|
|
* (and we want to avoid parsing blobs).
|
|
|
|
*/
|
|
|
|
if (obj->type == OBJ_NONE) {
|
|
|
|
enum object_type type = oid_object_info(the_repository,
|
|
|
|
&obj->oid, NULL);
|
|
|
|
if (type > 0)
|
2020-06-17 09:14:08 +00:00
|
|
|
object_as_type(obj, type, 0);
|
fsck: always compute USED flags for unreachable objects
The --connectivity-only option avoids opening every object, and instead
just marks reachable objects with a flag and compares this to the set
of all objects. This strategy is discussed in more detail in 3e3f8bd608
(fsck: prepare dummy objects for --connectivity-check, 2017-01-17).
This means that we report _every_ unreachable object as dangling.
Whereas in a full fsck, we'd have actually opened and parsed each of
those unreachable objects, marking their child objects with the USED
flag, to mean "this was mentioned by another object". And thus we can
report only the tip of an unreachable segment of the object graph as
dangling.
You can see this difference with a trivial example:
tree=$(git hash-object -t tree -w /dev/null)
one=$(echo one | git commit-tree $tree)
two=$(echo two | git commit-tree -p $one $tree)
Running `git fsck` will report only $two as dangling, but with
--connectivity-only, both commits (and the tree) are reported. Likewise,
using --lost-found would write all three objects.
We can make --connectivity-only work like the normal case by taking a
separate pass over the unreachable objects, parsing them and marking
objects they refer to as USED. That still avoids parsing any blobs,
though we do pay the cost to access any unreachable commits and trees
(which may or may not be noticeable, depending on how many you have).
If neither --dangling nor --lost-found is in effect, then we can skip
this step entirely, just like we do now. That makes "--connectivity-only
--no-dangling" just as fast as the current "--connectivity-only". I.e.,
we do the correct thing always, but you can still tweak the options to
make it faster if you don't care about dangling objects.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-05 04:47:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
options.walk = mark_used;
|
|
|
|
fsck_walk(obj, NULL, &options);
|
fsck: free tree buffers after walking unreachable objects
After calling fsck_walk(), a tree object struct may be left in the
parsed state, with the full tree contents available via tree->buffer.
It's the responsibility of the caller to free these when it's done with
the object to avoid having many trees allocated at once.
In a regular "git fsck", we hit fsck_walk() only from fsck_obj(), which
does call free_tree_buffer(). Likewise for "--connectivity-only", we see
most objects via traverse_one_object(), which makes a similar call.
The exception is in mark_unreachable_referents(). When using both
"--connectivity-only" and "--dangling" (the latter of which is the
default), we walk all of the unreachable objects, and there we forget to
free. Most cases would not notice this, because they don't have a lot of
unreachable objects, but you can make a pathological case like this:
git clone --bare /path/to/linux.git repo.git
cd repo.git
rm packed-refs ;# now everything is unreachable!
git fsck --connectivity-only
That ends up with peak heap usage ~18GB, which is (not coincidentally)
close to the size of all uncompressed trees in the repository. After
this patch, the peak heap is only ~2GB.
A few things to note:
- it might seem like fsck_walk(), if it is parsing the trees, should
be responsible for freeing them. But the situation is quite tricky.
In the non-connectivity mode, after we call fsck_walk() we then
proceed with fsck_object() which actually does the type-specific
sanity checks on the object contents. We do pass our own separate
buffer to fsck_object(), but there's a catch: our earlier call to
parse_object_buffer() may have attached that buffer to the object
struct! So by freeing it, we leave the rest of the code with a
dangling pointer.
Likewise, the call to fsck_walk() in index-pack is subtle. It
attaches a buffer to the tree object that must not be freed! And
so rather than calling free_tree_buffer(), it actually detaches it
by setting tree->buffer to NULL.
These cases would _probably_ be fixable by having fsck_walk() free
the tree buffer only when it was the one who allocated it via
parse_tree(). But that would still leave the callers responsible for
freeing other cases, so they wouldn't be simplified. While the
current semantics for fsck_walk() make it easy to accidentally leak
in new callers, at least they are simple to explain, and it's not a
function that's likely to get a lot of new call-sites.
And in any case, it's probably sensible to fix the leak first with
this simple patch, and try any more complicated refactoring
separately.
- a careful reader may notice that fsck_obj() also frees commit
buffers, but neither the call in traverse_one_object() nor the one
touched in this patch does so. And indeed, this is another problem
for --connectivity-only (and accounts for most of the 2GB heap after
this patch), but it's one we'll fix in a separate commit.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-09-22 10:11:43 +00:00
|
|
|
if (obj->type == OBJ_TREE)
|
|
|
|
free_tree_buffer((struct tree *)obj);
|
fsck: always compute USED flags for unreachable objects
The --connectivity-only option avoids opening every object, and instead
just marks reachable objects with a flag and compares this to the set
of all objects. This strategy is discussed in more detail in 3e3f8bd608
(fsck: prepare dummy objects for --connectivity-check, 2017-01-17).
This means that we report _every_ unreachable object as dangling.
Whereas in a full fsck, we'd have actually opened and parsed each of
those unreachable objects, marking their child objects with the USED
flag, to mean "this was mentioned by another object". And thus we can
report only the tip of an unreachable segment of the object graph as
dangling.
You can see this difference with a trivial example:
tree=$(git hash-object -t tree -w /dev/null)
one=$(echo one | git commit-tree $tree)
two=$(echo two | git commit-tree -p $one $tree)
Running `git fsck` will report only $two as dangling, but with
--connectivity-only, both commits (and the tree) are reported. Likewise,
using --lost-found would write all three objects.
We can make --connectivity-only work like the normal case by taking a
separate pass over the unreachable objects, parsing them and marking
objects they refer to as USED. That still avoids parsing any blobs,
though we do pay the cost to access any unreachable commits and trees
(which may or may not be noticeable, depending on how many you have).
If neither --dangling nor --lost-found is in effect, then we can skip
this step entirely, just like we do now. That makes "--connectivity-only
--no-dangling" just as fast as the current "--connectivity-only". I.e.,
we do the correct thing always, but you can still tweak the options to
make it faster if you don't care about dangling objects.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-05 04:47:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mark_loose_unreachable_referents(const struct object_id *oid,
|
2023-02-24 06:39:24 +00:00
|
|
|
const char *path UNUSED,
|
|
|
|
void *data UNUSED)
|
fsck: always compute USED flags for unreachable objects
The --connectivity-only option avoids opening every object, and instead
just marks reachable objects with a flag and compares this to the set
of all objects. This strategy is discussed in more detail in 3e3f8bd608
(fsck: prepare dummy objects for --connectivity-check, 2017-01-17).
This means that we report _every_ unreachable object as dangling.
Whereas in a full fsck, we'd have actually opened and parsed each of
those unreachable objects, marking their child objects with the USED
flag, to mean "this was mentioned by another object". And thus we can
report only the tip of an unreachable segment of the object graph as
dangling.
You can see this difference with a trivial example:
tree=$(git hash-object -t tree -w /dev/null)
one=$(echo one | git commit-tree $tree)
two=$(echo two | git commit-tree -p $one $tree)
Running `git fsck` will report only $two as dangling, but with
--connectivity-only, both commits (and the tree) are reported. Likewise,
using --lost-found would write all three objects.
We can make --connectivity-only work like the normal case by taking a
separate pass over the unreachable objects, parsing them and marking
objects they refer to as USED. That still avoids parsing any blobs,
though we do pay the cost to access any unreachable commits and trees
(which may or may not be noticeable, depending on how many you have).
If neither --dangling nor --lost-found is in effect, then we can skip
this step entirely, just like we do now. That makes "--connectivity-only
--no-dangling" just as fast as the current "--connectivity-only". I.e.,
we do the correct thing always, but you can still tweak the options to
make it faster if you don't care about dangling objects.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-05 04:47:39 +00:00
|
|
|
{
|
|
|
|
mark_unreachable_referents(oid);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mark_packed_unreachable_referents(const struct object_id *oid,
|
2023-02-24 06:39:24 +00:00
|
|
|
struct packed_git *pack UNUSED,
|
|
|
|
uint32_t pos UNUSED,
|
|
|
|
void *data UNUSED)
|
fsck: always compute USED flags for unreachable objects
The --connectivity-only option avoids opening every object, and instead
just marks reachable objects with a flag and compares this to the set
of all objects. This strategy is discussed in more detail in 3e3f8bd608
(fsck: prepare dummy objects for --connectivity-check, 2017-01-17).
This means that we report _every_ unreachable object as dangling.
Whereas in a full fsck, we'd have actually opened and parsed each of
those unreachable objects, marking their child objects with the USED
flag, to mean "this was mentioned by another object". And thus we can
report only the tip of an unreachable segment of the object graph as
dangling.
You can see this difference with a trivial example:
tree=$(git hash-object -t tree -w /dev/null)
one=$(echo one | git commit-tree $tree)
two=$(echo two | git commit-tree -p $one $tree)
Running `git fsck` will report only $two as dangling, but with
--connectivity-only, both commits (and the tree) are reported. Likewise,
using --lost-found would write all three objects.
We can make --connectivity-only work like the normal case by taking a
separate pass over the unreachable objects, parsing them and marking
objects they refer to as USED. That still avoids parsing any blobs,
though we do pay the cost to access any unreachable commits and trees
(which may or may not be noticeable, depending on how many you have).
If neither --dangling nor --lost-found is in effect, then we can skip
this step entirely, just like we do now. That makes "--connectivity-only
--no-dangling" just as fast as the current "--connectivity-only". I.e.,
we do the correct thing always, but you can still tweak the options to
make it faster if you don't care about dangling objects.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-05 04:47:39 +00:00
|
|
|
{
|
|
|
|
mark_unreachable_referents(oid);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-01-22 06:26:41 +00:00
|
|
|
/*
|
|
|
|
* Check a single reachable object
|
|
|
|
*/
|
|
|
|
static void check_reachable_object(struct object *obj)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We obviously want the object to be parsed,
|
|
|
|
* except if it was in a pack-file and we didn't
|
|
|
|
* do a full fsck
|
|
|
|
*/
|
2013-06-05 22:37:39 +00:00
|
|
|
if (!(obj->flags & HAS_OBJ)) {
|
2017-12-05 16:58:46 +00:00
|
|
|
if (is_promisor_object(&obj->oid))
|
|
|
|
return;
|
2018-05-02 00:25:33 +00:00
|
|
|
if (has_object_pack(&obj->oid))
|
2007-01-22 06:26:41 +00:00
|
|
|
return; /* it is in pack - forget about it */
|
2019-10-18 04:58:07 +00:00
|
|
|
printf_ln(_("missing %s %s"),
|
|
|
|
printable_type(&obj->oid, obj->type),
|
|
|
|
describe_object(&obj->oid));
|
2007-03-05 08:22:06 +00:00
|
|
|
errors_found |= ERROR_REACHABLE;
|
2007-01-22 06:26:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check a single unreachable object
|
|
|
|
*/
|
|
|
|
static void check_unreachable_object(struct object *obj)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Missing unreachable object? Ignore it. It's not like
|
|
|
|
* we miss it (since it can't be reached), nor do we want
|
|
|
|
* to complain about it being unreachable (since it does
|
|
|
|
* not exist).
|
|
|
|
*/
|
2017-01-16 21:25:35 +00:00
|
|
|
if (!(obj->flags & HAS_OBJ))
|
2007-01-22 06:26:41 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Unreachable object that exists? Show it if asked to,
|
|
|
|
* since this is something that is prunable.
|
|
|
|
*/
|
|
|
|
if (show_unreachable) {
|
2019-10-18 04:58:07 +00:00
|
|
|
printf_ln(_("unreachable %s %s"),
|
|
|
|
printable_type(&obj->oid, obj->type),
|
|
|
|
describe_object(&obj->oid));
|
2007-01-22 06:26:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-07-20 00:21:44 +00:00
|
|
|
* "!USED" means that nothing at all points to it, including
|
2007-02-04 04:49:16 +00:00
|
|
|
* other unreachable objects. In other words, it's the "tip"
|
2007-01-22 06:26:41 +00:00
|
|
|
* of some set of unreachable objects, usually a commit that
|
|
|
|
* got dropped.
|
|
|
|
*
|
|
|
|
* Such starting points are more interesting than some random
|
|
|
|
* set of unreachable objects, so we show them even if the user
|
|
|
|
* hasn't asked for _all_ unreachable objects. If you have
|
|
|
|
* deleted a branch by mistake, this is a prime candidate to
|
|
|
|
* start looking at, for example.
|
|
|
|
*/
|
2017-07-20 00:21:44 +00:00
|
|
|
if (!(obj->flags & USED)) {
|
2012-02-28 22:55:39 +00:00
|
|
|
if (show_dangling)
|
2019-10-18 04:58:07 +00:00
|
|
|
printf_ln(_("dangling %s %s"),
|
|
|
|
printable_type(&obj->oid, obj->type),
|
|
|
|
describe_object(&obj->oid));
|
2007-07-03 00:33:54 +00:00
|
|
|
if (write_lost_and_found) {
|
2015-08-10 09:35:31 +00:00
|
|
|
char *filename = git_pathdup("lost-found/%s/%s",
|
2007-07-03 00:33:54 +00:00
|
|
|
obj->type == OBJ_COMMIT ? "commit" : "other",
|
2019-10-18 04:58:07 +00:00
|
|
|
describe_object(&obj->oid));
|
2007-07-03 00:33:54 +00:00
|
|
|
FILE *f;
|
|
|
|
|
2014-11-30 08:24:27 +00:00
|
|
|
if (safe_create_leading_directories_const(filename)) {
|
2018-11-10 05:16:15 +00:00
|
|
|
error(_("could not create lost-found"));
|
2015-08-10 09:35:31 +00:00
|
|
|
free(filename);
|
2007-07-03 00:33:54 +00:00
|
|
|
return;
|
|
|
|
}
|
2017-05-03 10:16:46 +00:00
|
|
|
f = xfopen(filename, "w");
|
2007-07-22 20:20:26 +00:00
|
|
|
if (obj->type == OBJ_BLOB) {
|
2016-09-05 20:07:59 +00:00
|
|
|
if (stream_blob_to_fd(fileno(f), &obj->oid, NULL, 1))
|
2018-11-10 05:16:15 +00:00
|
|
|
die_errno(_("could not write '%s'"), filename);
|
2007-07-22 20:20:26 +00:00
|
|
|
} else
|
2019-10-18 04:58:07 +00:00
|
|
|
fprintf(f, "%s\n", describe_object(&obj->oid));
|
2008-12-05 00:35:48 +00:00
|
|
|
if (fclose(f))
|
2018-11-10 05:16:15 +00:00
|
|
|
die_errno(_("could not finish '%s'"),
|
2009-06-27 15:58:46 +00:00
|
|
|
filename);
|
2015-08-10 09:35:31 +00:00
|
|
|
free(filename);
|
2007-07-03 00:33:54 +00:00
|
|
|
}
|
2007-01-22 06:26:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Otherwise? It's there, it's unreachable, and some other unreachable
|
|
|
|
* object points to it. Ignore it - it's not interesting, and we showed
|
|
|
|
* all the interesting cases above.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
|
|
|
|
static void check_object(struct object *obj)
|
|
|
|
{
|
2007-06-05 02:44:00 +00:00
|
|
|
if (verbose)
|
2019-10-18 04:58:07 +00:00
|
|
|
fprintf_ln(stderr, _("Checking %s"), describe_object(&obj->oid));
|
2007-06-05 02:44:00 +00:00
|
|
|
|
2007-01-22 06:26:41 +00:00
|
|
|
if (obj->flags & REACHABLE)
|
|
|
|
check_reachable_object(obj);
|
|
|
|
else
|
|
|
|
check_unreachable_object(obj);
|
|
|
|
}
|
2005-09-20 18:56:05 +00:00
|
|
|
|
2005-04-11 06:13:09 +00:00
|
|
|
static void check_connectivity(void)
|
|
|
|
{
|
2006-06-30 04:38:55 +00:00
|
|
|
int i, max;
|
2005-04-11 06:13:09 +00:00
|
|
|
|
2008-12-11 03:44:37 +00:00
|
|
|
/* Traverse the pending reachable objects */
|
|
|
|
traverse_reachable();
|
|
|
|
|
fsck: always compute USED flags for unreachable objects
The --connectivity-only option avoids opening every object, and instead
just marks reachable objects with a flag and compares this to the set
of all objects. This strategy is discussed in more detail in 3e3f8bd608
(fsck: prepare dummy objects for --connectivity-check, 2017-01-17).
This means that we report _every_ unreachable object as dangling.
Whereas in a full fsck, we'd have actually opened and parsed each of
those unreachable objects, marking their child objects with the USED
flag, to mean "this was mentioned by another object". And thus we can
report only the tip of an unreachable segment of the object graph as
dangling.
You can see this difference with a trivial example:
tree=$(git hash-object -t tree -w /dev/null)
one=$(echo one | git commit-tree $tree)
two=$(echo two | git commit-tree -p $one $tree)
Running `git fsck` will report only $two as dangling, but with
--connectivity-only, both commits (and the tree) are reported. Likewise,
using --lost-found would write all three objects.
We can make --connectivity-only work like the normal case by taking a
separate pass over the unreachable objects, parsing them and marking
objects they refer to as USED. That still avoids parsing any blobs,
though we do pay the cost to access any unreachable commits and trees
(which may or may not be noticeable, depending on how many you have).
If neither --dangling nor --lost-found is in effect, then we can skip
this step entirely, just like we do now. That makes "--connectivity-only
--no-dangling" just as fast as the current "--connectivity-only". I.e.,
we do the correct thing always, but you can still tweak the options to
make it faster if you don't care about dangling objects.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-05 04:47:39 +00:00
|
|
|
/*
|
|
|
|
* With --connectivity-only, we won't have actually opened and marked
|
|
|
|
* unreachable objects with USED. Do that now to make --dangling, etc
|
|
|
|
* accurate.
|
|
|
|
*/
|
|
|
|
if (connectivity_only && (show_dangling || write_lost_and_found)) {
|
|
|
|
/*
|
|
|
|
* Even though we already have a "struct object" for each of
|
|
|
|
* these in memory, we must not iterate over the internal
|
|
|
|
* object hash as we do below. Our loop would potentially
|
|
|
|
* resize the hash, making our iteration invalid.
|
|
|
|
*
|
|
|
|
* Instead, we'll just go back to the source list of objects,
|
|
|
|
* and ignore any that weren't present in our earlier
|
|
|
|
* traversal.
|
|
|
|
*/
|
|
|
|
for_each_loose_object(mark_loose_unreachable_referents, NULL, 0);
|
|
|
|
for_each_packed_object(mark_packed_unreachable_referents, NULL, 0);
|
|
|
|
}
|
|
|
|
|
2005-04-11 06:13:09 +00:00
|
|
|
/* Look up all the requirements, warn about missing objects.. */
|
2006-06-30 04:38:55 +00:00
|
|
|
max = get_max_object_index();
|
2007-06-05 02:44:00 +00:00
|
|
|
if (verbose)
|
2018-11-10 05:16:15 +00:00
|
|
|
fprintf_ln(stderr, _("Checking connectivity (%d objects)"), max);
|
2007-06-05 02:44:00 +00:00
|
|
|
|
2006-06-30 04:38:55 +00:00
|
|
|
for (i = 0; i < max; i++) {
|
|
|
|
struct object *obj = get_indexed_object(i);
|
2005-04-11 06:13:09 +00:00
|
|
|
|
2007-01-22 06:26:41 +00:00
|
|
|
if (obj)
|
|
|
|
check_object(obj);
|
2005-04-11 06:13:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
fsck: actually fsck blob data
Because fscking a blob has always been a noop, we didn't
bother passing around the blob data. In preparation for
content-level checks, let's fix up a few things:
1. The fsck_object() function just returns success for any
blob. Let's a noop fsck_blob(), which we can fill in
with actual logic later.
2. The fsck_loose() function in builtin/fsck.c
just threw away blob content after loading it. Let's
hold onto it until after we've called fsck_object().
The easiest way to do this is to just drop the
parse_loose_object() helper entirely. Incidentally,
this also fixes a memory leak: if we successfully
loaded the object data but did not parse it, we would
have left the function without freeing it.
3. When fsck_loose() loads the object data, it
does so with a custom read_loose_object() helper. This
function streams any blobs, regardless of size, under
the assumption that we're only checking the sha1.
Instead, let's actually load blobs smaller than
big_file_threshold, as the normal object-reading
code-paths would do. This lets us fsck small files, and
a NULL return is an indication that the blob was so big
that it needed to be streamed, and we can pass that
information along to fsck_blob().
Signed-off-by: Jeff King <peff@peff.net>
2018-05-02 19:44:51 +00:00
|
|
|
static int fsck_obj(struct object *obj, void *buffer, unsigned long size)
|
2005-05-02 23:13:18 +00:00
|
|
|
{
|
2017-08-10 09:42:10 +00:00
|
|
|
int err;
|
|
|
|
|
2008-02-25 21:46:08 +00:00
|
|
|
if (obj->flags & SEEN)
|
2005-05-02 23:13:18 +00:00
|
|
|
return 0;
|
2008-02-25 21:46:08 +00:00
|
|
|
obj->flags |= SEEN;
|
2005-05-02 23:13:18 +00:00
|
|
|
|
2007-06-05 02:44:00 +00:00
|
|
|
if (verbose)
|
2018-11-10 05:16:15 +00:00
|
|
|
fprintf_ln(stderr, _("Checking %s %s"),
|
2019-10-18 04:58:07 +00:00
|
|
|
printable_type(&obj->oid, obj->type),
|
|
|
|
describe_object(&obj->oid));
|
2005-05-05 23:18:48 +00:00
|
|
|
|
2015-06-22 15:25:00 +00:00
|
|
|
if (fsck_walk(obj, NULL, &fsck_obj_options))
|
2018-11-10 05:16:15 +00:00
|
|
|
objerror(obj, _("broken links"));
|
fsck: actually fsck blob data
Because fscking a blob has always been a noop, we didn't
bother passing around the blob data. In preparation for
content-level checks, let's fix up a few things:
1. The fsck_object() function just returns success for any
blob. Let's a noop fsck_blob(), which we can fill in
with actual logic later.
2. The fsck_loose() function in builtin/fsck.c
just threw away blob content after loading it. Let's
hold onto it until after we've called fsck_object().
The easiest way to do this is to just drop the
parse_loose_object() helper entirely. Incidentally,
this also fixes a memory leak: if we successfully
loaded the object data but did not parse it, we would
have left the function without freeing it.
3. When fsck_loose() loads the object data, it
does so with a custom read_loose_object() helper. This
function streams any blobs, regardless of size, under
the assumption that we're only checking the sha1.
Instead, let's actually load blobs smaller than
big_file_threshold, as the normal object-reading
code-paths would do. This lets us fsck small files, and
a NULL return is an indication that the blob was so big
that it needed to be streamed, and we can pass that
information along to fsck_blob().
Signed-off-by: Jeff King <peff@peff.net>
2018-05-02 19:44:51 +00:00
|
|
|
err = fsck_object(obj, buffer, size, &fsck_obj_options);
|
2017-08-10 09:42:10 +00:00
|
|
|
if (err)
|
|
|
|
goto out;
|
2005-04-09 00:11:14 +00:00
|
|
|
|
2008-02-25 21:46:08 +00:00
|
|
|
if (obj->type == OBJ_COMMIT) {
|
|
|
|
struct commit *commit = (struct commit *) obj;
|
2005-07-27 22:16:03 +00:00
|
|
|
|
2008-02-25 21:46:08 +00:00
|
|
|
if (!commit->parents && show_root)
|
2018-11-10 05:16:15 +00:00
|
|
|
printf_ln(_("root %s"),
|
2019-10-18 04:58:07 +00:00
|
|
|
describe_object(&commit->object.oid));
|
2008-02-25 21:46:08 +00:00
|
|
|
}
|
2005-05-03 14:57:56 +00:00
|
|
|
|
2008-02-25 21:46:08 +00:00
|
|
|
if (obj->type == OBJ_TAG) {
|
|
|
|
struct tag *tag = (struct tag *) obj;
|
2007-06-05 02:44:00 +00:00
|
|
|
|
2008-02-25 21:46:08 +00:00
|
|
|
if (show_tags && tag->tagged) {
|
2018-11-10 05:16:15 +00:00
|
|
|
printf_ln(_("tagged %s %s (%s) in %s"),
|
2019-10-18 04:58:07 +00:00
|
|
|
printable_type(&tag->tagged->oid, tag->tagged->type),
|
|
|
|
describe_object(&tag->tagged->oid),
|
2018-11-10 05:16:14 +00:00
|
|
|
tag->tag,
|
2019-10-18 04:58:07 +00:00
|
|
|
describe_object(&tag->object.oid));
|
2008-02-25 21:46:08 +00:00
|
|
|
}
|
2005-05-03 14:57:56 +00:00
|
|
|
}
|
2005-04-25 23:31:13 +00:00
|
|
|
|
2017-08-10 09:42:10 +00:00
|
|
|
out:
|
|
|
|
if (obj->type == OBJ_TREE)
|
|
|
|
free_tree_buffer((struct tree *)obj);
|
|
|
|
return err;
|
2005-04-08 22:02:42 +00:00
|
|
|
}
|
|
|
|
|
2017-05-06 22:10:20 +00:00
|
|
|
static int fsck_obj_buffer(const struct object_id *oid, enum object_type type,
|
2011-11-07 02:59:25 +00:00
|
|
|
unsigned long size, void *buffer, int *eaten)
|
|
|
|
{
|
fsck: use streaming interface for large blobs in pack
For blobs, we want to make sure the on-disk data is not corrupted
(i.e. can be inflated and produce the expected SHA-1). Blob content is
opaque, there's nothing else inside to check for.
For really large blobs, we may want to avoid unpacking the entire blob
in memory, just to check whether it produces the same SHA-1. On 32-bit
systems, we may not have enough virtual address space for such memory
allocation. And even on 64-bit where it's not a problem, allocating a
lot more memory could result in kicking other parts of systems to swap
file, generating lots of I/O and slowing everything down.
For this particular operation, not unpacking the blob and letting
check_sha1_signature, which supports streaming interface, do the job
is sufficient. check_sha1_signature() is not shown in the diff,
unfortunately. But if will be called when "data_valid && !data" is
false.
We will call the callback function "fn" with NULL as "data". The only
callback of this function is fsck_obj_buffer(), which does not touch
"data" at all if it's a blob.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13 15:44:04 +00:00
|
|
|
/*
|
|
|
|
* Note, buffer may be NULL if type is OBJ_BLOB. See
|
|
|
|
* verify_packfile(), data_valid variable for details.
|
|
|
|
*/
|
2011-11-07 02:59:25 +00:00
|
|
|
struct object *obj;
|
2018-06-29 01:21:53 +00:00
|
|
|
obj = parse_object_buffer(the_repository, oid, type, size, buffer,
|
|
|
|
eaten);
|
2011-11-07 02:59:25 +00:00
|
|
|
if (!obj) {
|
|
|
|
errors_found |= ERROR_OBJECT;
|
2018-11-10 05:16:15 +00:00
|
|
|
return error(_("%s: object corrupt or missing"),
|
|
|
|
oid_to_hex(oid));
|
2011-11-07 02:59:25 +00:00
|
|
|
}
|
2017-07-20 00:21:44 +00:00
|
|
|
obj->flags &= ~(REACHABLE | SEEN);
|
|
|
|
obj->flags |= HAS_OBJ;
|
fsck: actually fsck blob data
Because fscking a blob has always been a noop, we didn't
bother passing around the blob data. In preparation for
content-level checks, let's fix up a few things:
1. The fsck_object() function just returns success for any
blob. Let's a noop fsck_blob(), which we can fill in
with actual logic later.
2. The fsck_loose() function in builtin/fsck.c
just threw away blob content after loading it. Let's
hold onto it until after we've called fsck_object().
The easiest way to do this is to just drop the
parse_loose_object() helper entirely. Incidentally,
this also fixes a memory leak: if we successfully
loaded the object data but did not parse it, we would
have left the function without freeing it.
3. When fsck_loose() loads the object data, it
does so with a custom read_loose_object() helper. This
function streams any blobs, regardless of size, under
the assumption that we're only checking the sha1.
Instead, let's actually load blobs smaller than
big_file_threshold, as the normal object-reading
code-paths would do. This lets us fsck small files, and
a NULL return is an indication that the blob was so big
that it needed to be streamed, and we can pass that
information along to fsck_blob().
Signed-off-by: Jeff King <peff@peff.net>
2018-05-02 19:44:51 +00:00
|
|
|
return fsck_obj(obj, buffer, size);
|
2011-11-07 02:59:25 +00:00
|
|
|
}
|
|
|
|
|
2006-08-15 17:23:48 +00:00
|
|
|
static int default_refs;
|
2005-07-03 17:01:38 +00:00
|
|
|
|
2017-02-21 23:47:32 +00:00
|
|
|
static void fsck_handle_reflog_oid(const char *refname, struct object_id *oid,
|
2017-04-26 19:29:31 +00:00
|
|
|
timestamp_t timestamp)
|
2006-12-18 09:36:16 +00:00
|
|
|
{
|
|
|
|
struct object *obj;
|
|
|
|
|
2017-02-21 23:47:32 +00:00
|
|
|
if (!is_null_oid(oid)) {
|
2019-06-20 07:41:14 +00:00
|
|
|
obj = lookup_object(the_repository, oid);
|
2017-01-16 21:34:57 +00:00
|
|
|
if (obj && (obj->flags & HAS_OBJ)) {
|
fsck: unify object-name code
Commit 90cf590f53 (fsck: optionally show more helpful info for broken
links, 2016-07-17) added a system for decorating objects with names. The
code is split across builtin/fsck.c (which gives the initial names) and
fsck.c (which adds to the names as it traverses the object graph). This
leads to some duplication, where both sites have near-identical
describe_object() functions (the difference being that the one in
builtin/fsck.c uses a circular array of buffers to allow multiple calls
in a single printf).
Let's provide a unified object_name API for fsck. That lets us drop the
duplication, as well as making the interface boundaries more clear
(which will let us refactor the implementation more in a future patch).
We'll leave describe_object() in builtin/fsck.c as a thin wrapper around
the new API, as it relies on a static global to make its many callers a
bit shorter.
We'll also convert the bare add_decoration() calls in builtin/fsck.c to
put_object_name(). This fixes two minor bugs:
1. We leak many small strings. add_decoration() has a last-one-wins
approach: it updates the decoration to the new string and returns
the old one. But we ignore the return value, leaking the old
string. This is quite common to trigger, since we look at reflogs:
the tip of any ref will be described both by looking at the actual
ref, as well as the latest reflog entry. So we'd always end up
leaking one of those strings.
2. The last-one-wins approach gives us lousy names. For instance, we
first look at all of the refs, and then all of the reflogs. So
rather than seeing "refs/heads/master", we're likely to overwrite
it with "HEAD@{12345678}". We're generally better off using the
first name we find.
And indeed, the test in t1450 expects this ugly HEAD@{} name. After
this patch, we've switched to using fsck_put_object_name()'s
first-one-wins semantics, and we output the more human-friendly
"refs/tags/julius" (and the test is updated accordingly).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18 04:56:13 +00:00
|
|
|
if (timestamp)
|
2019-10-18 04:57:37 +00:00
|
|
|
fsck_put_object_name(&fsck_walk_options, oid,
|
fsck: unify object-name code
Commit 90cf590f53 (fsck: optionally show more helpful info for broken
links, 2016-07-17) added a system for decorating objects with names. The
code is split across builtin/fsck.c (which gives the initial names) and
fsck.c (which adds to the names as it traverses the object graph). This
leads to some duplication, where both sites have near-identical
describe_object() functions (the difference being that the one in
builtin/fsck.c uses a circular array of buffers to allow multiple calls
in a single printf).
Let's provide a unified object_name API for fsck. That lets us drop the
duplication, as well as making the interface boundaries more clear
(which will let us refactor the implementation more in a future patch).
We'll leave describe_object() in builtin/fsck.c as a thin wrapper around
the new API, as it relies on a static global to make its many callers a
bit shorter.
We'll also convert the bare add_decoration() calls in builtin/fsck.c to
put_object_name(). This fixes two minor bugs:
1. We leak many small strings. add_decoration() has a last-one-wins
approach: it updates the decoration to the new string and returns
the old one. But we ignore the return value, leaking the old
string. This is quite common to trigger, since we look at reflogs:
the tip of any ref will be described both by looking at the actual
ref, as well as the latest reflog entry. So we'd always end up
leaking one of those strings.
2. The last-one-wins approach gives us lousy names. For instance, we
first look at all of the refs, and then all of the reflogs. So
rather than seeing "refs/heads/master", we're likely to overwrite
it with "HEAD@{12345678}". We're generally better off using the
first name we find.
And indeed, the test in t1450 expects this ugly HEAD@{} name. After
this patch, we've switched to using fsck_put_object_name()'s
first-one-wins semantics, and we output the more human-friendly
"refs/tags/julius" (and the test is updated accordingly).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18 04:56:13 +00:00
|
|
|
"%s@{%"PRItime"}",
|
|
|
|
refname, timestamp);
|
2017-07-20 00:21:44 +00:00
|
|
|
obj->flags |= USED;
|
2008-02-25 21:46:05 +00:00
|
|
|
mark_object_reachable(obj);
|
2017-12-05 16:58:44 +00:00
|
|
|
} else if (!is_promisor_object(oid)) {
|
2018-11-10 05:16:15 +00:00
|
|
|
error(_("%s: invalid reflog entry %s"),
|
|
|
|
refname, oid_to_hex(oid));
|
2015-06-08 13:40:05 +00:00
|
|
|
errors_found |= ERROR_REACHABLE;
|
2006-12-18 09:36:16 +00:00
|
|
|
}
|
|
|
|
}
|
2015-06-08 13:40:04 +00:00
|
|
|
}
|
|
|
|
|
2017-02-21 23:47:32 +00:00
|
|
|
static int fsck_handle_reflog_ent(struct object_id *ooid, struct object_id *noid,
|
2022-08-25 17:09:48 +00:00
|
|
|
const char *email UNUSED,
|
|
|
|
timestamp_t timestamp, int tz UNUSED,
|
|
|
|
const char *message UNUSED, void *cb_data)
|
2006-12-18 09:36:16 +00:00
|
|
|
{
|
2015-06-08 13:40:05 +00:00
|
|
|
const char *refname = cb_data;
|
2006-12-18 09:36:16 +00:00
|
|
|
|
2007-06-05 02:44:00 +00:00
|
|
|
if (verbose)
|
2018-11-10 05:16:15 +00:00
|
|
|
fprintf_ln(stderr, _("Checking reflog %s->%s"),
|
|
|
|
oid_to_hex(ooid), oid_to_hex(noid));
|
2007-06-05 02:44:00 +00:00
|
|
|
|
2017-02-21 23:47:32 +00:00
|
|
|
fsck_handle_reflog_oid(refname, ooid, 0);
|
|
|
|
fsck_handle_reflog_oid(refname, noid, timestamp);
|
2006-12-18 09:36:16 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-08-19 10:08:32 +00:00
|
|
|
static int fsck_handle_reflog(const char *logname,
|
2022-08-25 17:09:48 +00:00
|
|
|
const struct object_id *oid UNUSED,
|
|
|
|
int flag UNUSED, void *cb_data)
|
2007-02-03 18:25:43 +00:00
|
|
|
{
|
2018-10-21 08:08:58 +00:00
|
|
|
struct strbuf refname = STRBUF_INIT;
|
|
|
|
|
|
|
|
strbuf_worktree_ref(cb_data, &refname, logname);
|
|
|
|
for_each_reflog_ent(refname.buf, fsck_handle_reflog_ent, refname.buf);
|
|
|
|
strbuf_release(&refname);
|
2007-02-03 18:25:43 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-05-25 18:38:50 +00:00
|
|
|
static int fsck_handle_ref(const char *refname, const struct object_id *oid,
|
2022-08-25 17:09:48 +00:00
|
|
|
int flag UNUSED, void *cb_data UNUSED)
|
2005-05-18 17:16:14 +00:00
|
|
|
{
|
|
|
|
struct object *obj;
|
|
|
|
|
2018-06-29 01:21:51 +00:00
|
|
|
obj = parse_object(the_repository, oid);
|
2005-06-28 21:58:33 +00:00
|
|
|
if (!obj) {
|
2017-12-05 16:58:45 +00:00
|
|
|
if (is_promisor_object(oid)) {
|
|
|
|
/*
|
|
|
|
* Increment default_refs anyway, because this is a
|
|
|
|
* valid ref.
|
|
|
|
*/
|
|
|
|
default_refs++;
|
|
|
|
return 0;
|
|
|
|
}
|
2018-11-10 05:16:15 +00:00
|
|
|
error(_("%s: invalid sha1 pointer %s"),
|
|
|
|
refname, oid_to_hex(oid));
|
2014-09-12 03:38:30 +00:00
|
|
|
errors_found |= ERROR_REACHABLE;
|
2005-07-03 17:01:38 +00:00
|
|
|
/* We'll continue with the rest despite the error.. */
|
|
|
|
return 0;
|
2005-06-28 21:58:33 +00:00
|
|
|
}
|
2015-09-23 20:46:39 +00:00
|
|
|
if (obj->type != OBJ_COMMIT && is_branch(refname)) {
|
2018-11-10 05:16:15 +00:00
|
|
|
error(_("%s: not a commit"), refname);
|
2015-09-23 20:46:39 +00:00
|
|
|
errors_found |= ERROR_REFS;
|
|
|
|
}
|
2005-07-03 17:01:38 +00:00
|
|
|
default_refs++;
|
2017-07-20 00:21:44 +00:00
|
|
|
obj->flags |= USED;
|
fsck: unify object-name code
Commit 90cf590f53 (fsck: optionally show more helpful info for broken
links, 2016-07-17) added a system for decorating objects with names. The
code is split across builtin/fsck.c (which gives the initial names) and
fsck.c (which adds to the names as it traverses the object graph). This
leads to some duplication, where both sites have near-identical
describe_object() functions (the difference being that the one in
builtin/fsck.c uses a circular array of buffers to allow multiple calls
in a single printf).
Let's provide a unified object_name API for fsck. That lets us drop the
duplication, as well as making the interface boundaries more clear
(which will let us refactor the implementation more in a future patch).
We'll leave describe_object() in builtin/fsck.c as a thin wrapper around
the new API, as it relies on a static global to make its many callers a
bit shorter.
We'll also convert the bare add_decoration() calls in builtin/fsck.c to
put_object_name(). This fixes two minor bugs:
1. We leak many small strings. add_decoration() has a last-one-wins
approach: it updates the decoration to the new string and returns
the old one. But we ignore the return value, leaking the old
string. This is quite common to trigger, since we look at reflogs:
the tip of any ref will be described both by looking at the actual
ref, as well as the latest reflog entry. So we'd always end up
leaking one of those strings.
2. The last-one-wins approach gives us lousy names. For instance, we
first look at all of the refs, and then all of the reflogs. So
rather than seeing "refs/heads/master", we're likely to overwrite
it with "HEAD@{12345678}". We're generally better off using the
first name we find.
And indeed, the test in t1450 expects this ugly HEAD@{} name. After
this patch, we've switched to using fsck_put_object_name()'s
first-one-wins semantics, and we output the more human-friendly
"refs/tags/julius" (and the test is updated accordingly).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18 04:56:13 +00:00
|
|
|
fsck_put_object_name(&fsck_walk_options,
|
2019-10-18 04:57:37 +00:00
|
|
|
oid, "%s", refname);
|
2008-02-25 21:46:05 +00:00
|
|
|
mark_object_reachable(obj);
|
2006-12-18 09:36:16 +00:00
|
|
|
|
2005-05-20 14:49:17 +00:00
|
|
|
return 0;
|
2005-05-18 17:16:14 +00:00
|
|
|
}
|
|
|
|
|
2018-10-21 08:08:58 +00:00
|
|
|
static int fsck_head_link(const char *head_ref_name,
|
|
|
|
const char **head_points_at,
|
2018-10-21 08:08:57 +00:00
|
|
|
struct object_id *head_oid);
|
|
|
|
|
2005-05-18 17:16:14 +00:00
|
|
|
static void get_default_heads(void)
|
|
|
|
{
|
2018-10-21 08:08:58 +00:00
|
|
|
struct worktree **worktrees, **p;
|
2018-10-21 08:08:57 +00:00
|
|
|
const char *head_points_at;
|
|
|
|
struct object_id head_oid;
|
|
|
|
|
2015-05-25 18:38:50 +00:00
|
|
|
for_each_rawref(fsck_handle_ref, NULL);
|
2018-10-21 08:08:58 +00:00
|
|
|
|
2020-06-19 23:35:44 +00:00
|
|
|
worktrees = get_worktrees();
|
2018-10-21 08:08:58 +00:00
|
|
|
for (p = worktrees; *p; p++) {
|
|
|
|
struct worktree *wt = *p;
|
|
|
|
struct strbuf ref = STRBUF_INIT;
|
|
|
|
|
|
|
|
strbuf_worktree_ref(wt, &ref, "HEAD");
|
|
|
|
fsck_head_link(ref.buf, &head_points_at, &head_oid);
|
|
|
|
if (head_points_at && !is_null_oid(&head_oid))
|
|
|
|
fsck_handle_ref(ref.buf, &head_oid, 0, NULL);
|
|
|
|
strbuf_release(&ref);
|
|
|
|
|
|
|
|
if (include_reflogs)
|
|
|
|
refs_for_each_reflog(get_worktree_ref_store(wt),
|
|
|
|
fsck_handle_reflog, wt);
|
|
|
|
}
|
|
|
|
free_worktrees(worktrees);
|
2006-08-29 18:47:30 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Not having any default heads isn't really fatal, but
|
|
|
|
* it does mean that "--unreachable" no longer makes any
|
|
|
|
* sense (since in this case everything will obviously
|
|
|
|
* be unreachable by definition.
|
|
|
|
*
|
|
|
|
* Showing dangling objects is valid, though (as those
|
|
|
|
* dangling objects are likely lost heads).
|
|
|
|
*
|
|
|
|
* So we just print a warning about it, and clear the
|
|
|
|
* "show_unreachable" flag.
|
|
|
|
*/
|
|
|
|
if (!default_refs) {
|
2018-11-10 05:16:15 +00:00
|
|
|
fprintf_ln(stderr, _("notice: No default references"));
|
2006-08-29 18:47:30 +00:00
|
|
|
show_unreachable = 0;
|
|
|
|
}
|
2005-05-18 17:16:14 +00:00
|
|
|
}
|
|
|
|
|
2021-10-01 09:16:52 +00:00
|
|
|
struct for_each_loose_cb
|
|
|
|
{
|
|
|
|
struct progress *progress;
|
|
|
|
struct strbuf obj_type;
|
|
|
|
};
|
|
|
|
|
fsck: actually fsck blob data
Because fscking a blob has always been a noop, we didn't
bother passing around the blob data. In preparation for
content-level checks, let's fix up a few things:
1. The fsck_object() function just returns success for any
blob. Let's a noop fsck_blob(), which we can fill in
with actual logic later.
2. The fsck_loose() function in builtin/fsck.c
just threw away blob content after loading it. Let's
hold onto it until after we've called fsck_object().
The easiest way to do this is to just drop the
parse_loose_object() helper entirely. Incidentally,
this also fixes a memory leak: if we successfully
loaded the object data but did not parse it, we would
have left the function without freeing it.
3. When fsck_loose() loads the object data, it
does so with a custom read_loose_object() helper. This
function streams any blobs, regardless of size, under
the assumption that we're only checking the sha1.
Instead, let's actually load blobs smaller than
big_file_threshold, as the normal object-reading
code-paths would do. This lets us fsck small files, and
a NULL return is an indication that the blob was so big
that it needed to be streamed, and we can pass that
information along to fsck_blob().
Signed-off-by: Jeff King <peff@peff.net>
2018-05-02 19:44:51 +00:00
|
|
|
static int fsck_loose(const struct object_id *oid, const char *path, void *data)
|
fsck: parse loose object paths directly
When we iterate over the list of loose objects to check, we
get the actual path of each object. But we then throw it
away and pass just the sha1 to fsck_sha1(), which will do a
fresh lookup. Usually it would find the same object, but it
may not if an object exists both as a loose and a packed
object. We may end up checking the packed object twice, and
never look at the loose one.
In practice this isn't too terrible, because if fsck doesn't
complain, it means you have at least one good copy. But
since the point of fsck is to look for corruption, we should
be thorough.
The new read_loose_object() interface can help us get the
data from disk, and then we replace parse_object() with
parse_object_buffer(). As a bonus, our error messages now
mention the path to a corrupted object, which should make it
easier to track down errors when they do happen.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 17:59:44 +00:00
|
|
|
{
|
2021-10-01 09:16:52 +00:00
|
|
|
struct for_each_loose_cb *cb_data = data;
|
fsck: parse loose object paths directly
When we iterate over the list of loose objects to check, we
get the actual path of each object. But we then throw it
away and pass just the sha1 to fsck_sha1(), which will do a
fresh lookup. Usually it would find the same object, but it
may not if an object exists both as a loose and a packed
object. We may end up checking the packed object twice, and
never look at the loose one.
In practice this isn't too terrible, because if fsck doesn't
complain, it means you have at least one good copy. But
since the point of fsck is to look for corruption, we should
be thorough.
The new read_loose_object() interface can help us get the
data from disk, and then we replace parse_object() with
parse_object_buffer(). As a bonus, our error messages now
mention the path to a corrupted object, which should make it
easier to track down errors when they do happen.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 17:59:44 +00:00
|
|
|
struct object *obj;
|
2021-10-01 09:16:52 +00:00
|
|
|
enum object_type type = OBJ_NONE;
|
fsck: parse loose object paths directly
When we iterate over the list of loose objects to check, we
get the actual path of each object. But we then throw it
away and pass just the sha1 to fsck_sha1(), which will do a
fresh lookup. Usually it would find the same object, but it
may not if an object exists both as a loose and a packed
object. We may end up checking the packed object twice, and
never look at the loose one.
In practice this isn't too terrible, because if fsck doesn't
complain, it means you have at least one good copy. But
since the point of fsck is to look for corruption, we should
be thorough.
The new read_loose_object() interface can help us get the
data from disk, and then we replace parse_object() with
parse_object_buffer(). As a bonus, our error messages now
mention the path to a corrupted object, which should make it
easier to track down errors when they do happen.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 17:59:44 +00:00
|
|
|
unsigned long size;
|
object-file: free(*contents) only in read_loose_object() caller
In the preceding commit a free() of uninitialized memory regression in
96e41f58fe1 (fsck: report invalid object type-path combinations,
2021-10-01) was fixed, but we'd still have an issue with leaking
memory from fsck_loose(). Let's fix that issue too.
That issue was introduced in my 31deb28f5e0 (fsck: don't hard die on
invalid object types, 2021-10-01). It can be reproduced under
SANITIZE=leak with the test I added in 093fffdfbec (fsck tests: add
test for fsck-ing an unknown type, 2021-10-01):
./t1450-fsck.sh --run=84 -vixd
In some sense it's not a problem, we lost the same amount of memory in
terms of things malloc'd and not free'd. It just moved from the "still
reachable" to "definitely lost" column in valgrind(1) nomenclature[1],
since we'd have die()'d before.
But now that we don't hard die() anymore in the library let's properly
free() it. Doing so makes this code much easier to follow, since we'll
now have one function owning the freeing of the "contents" variable,
not two.
For context on that memory management pattern the read_loose_object()
function was added in f6371f92104 (sha1_file: add read_loose_object()
function, 2017-01-13) and subsequently used in c68b489e564 (fsck:
parse loose object paths directly, 2017-01-13). The pattern of it
being the task of both sides to free() the memory has been there in
this form since its inception.
1. https://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-11 05:18:56 +00:00
|
|
|
void *contents = NULL;
|
fsck: parse loose object paths directly
When we iterate over the list of loose objects to check, we
get the actual path of each object. But we then throw it
away and pass just the sha1 to fsck_sha1(), which will do a
fresh lookup. Usually it would find the same object, but it
may not if an object exists both as a loose and a packed
object. We may end up checking the packed object twice, and
never look at the loose one.
In practice this isn't too terrible, because if fsck doesn't
complain, it means you have at least one good copy. But
since the point of fsck is to look for corruption, we should
be thorough.
The new read_loose_object() interface can help us get the
data from disk, and then we replace parse_object() with
parse_object_buffer(). As a bonus, our error messages now
mention the path to a corrupted object, which should make it
easier to track down errors when they do happen.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 17:59:44 +00:00
|
|
|
int eaten;
|
2021-10-01 09:16:52 +00:00
|
|
|
struct object_info oi = OBJECT_INFO_INIT;
|
fsck: report invalid object type-path combinations
Improve the error that's emitted in cases where we find a loose object
we parse, but which isn't at the location we expect it to be.
Before this change we'd prefix the error with a not-a-OID derived from
the path at which the object was found, due to an emergent behavior in
how we'd end up with an "OID" in these codepaths.
Now we'll instead say what object we hashed, and what path it was
found at. Before this patch series e.g.:
$ git hash-object --stdin -w -t blob </dev/null
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ mv objects/e6/ objects/e7
Would emit ("[...]" used to abbreviate the OIDs):
git fsck
error: hash mismatch for ./objects/e7/9d[...] (expected e79d[...])
error: e79d[...]: object corrupt or missing: ./objects/e7/9d[...]
Now we'll instead emit:
error: e69d[...]: hash-path mismatch, found at: ./objects/e7/9d[...]
Furthermore, we'll do the right thing when the object type and its
location are bad. I.e. this case:
$ git hash-object --stdin -w -t garbage --literally </dev/null
8315a83d2acc4c174aed59430f9a9c4ed926440f
$ mv objects/83 objects/84
As noted in an earlier commits we'd simply die early in those cases,
until preceding commits fixed the hard die on invalid object type:
$ git fsck
fatal: invalid object type
Now we'll instead emit sensible error messages:
$ git fsck
error: 8315[...]: hash-path mismatch, found at: ./objects/84/15[...]
error: 8315[...]: object is of unknown type 'garbage': ./objects/84/15[...]
In both fsck.c and object-file.c we're using null_oid as a sentinel
value for checking whether we got far enough to be certain that the
issue was indeed this OID mismatch.
We need to add the "object corrupt or missing" special-case to deal
with cases where read_loose_object() will return an error before
completing check_object_signature(), e.g. if we have an error in
unpack_loose_rest() because we find garbage after the valid gzip
content:
$ git hash-object --stdin -w -t blob </dev/null
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ chmod 755 objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ echo garbage >>objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ git fsck
error: garbage at end of loose object 'e69d[...]'
error: unable to unpack contents of ./objects/e6/9d[...]
error: e69d[...]: object corrupt or missing: ./objects/e6/9d[...]
There is currently some weird messaging in the edge case when the two
are combined, i.e. because we're not explicitly passing along an error
state about this specific scenario from check_stream_oid() via
read_loose_object() we'll end up printing the null OID if an object is
of an unknown type *and* it can't be unpacked by zlib, e.g.:
$ git hash-object --stdin -w -t garbage --literally </dev/null
8315a83d2acc4c174aed59430f9a9c4ed926440f
$ chmod 755 objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
$ echo garbage >>objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
$ /usr/bin/git fsck
fatal: invalid object type
$ ~/g/git/git fsck
error: garbage at end of loose object '8315a83d2acc4c174aed59430f9a9c4ed926440f'
error: unable to unpack contents of ./objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
error: 8315a83d2acc4c174aed59430f9a9c4ed926440f: object corrupt or missing: ./objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
error: 0000000000000000000000000000000000000000: object is of unknown type 'garbage': ./objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
[...]
I think it's OK to leave that for future improvements, which would
involve enum-ifying more error state as we've done with "enum
unpack_loose_header_result" in preceding commits. In these
increasingly more obscure cases the worst that can happen is that
we'll get slightly nonsensical or inapplicable error messages.
There's other such potential edge cases, all of which might produce
some confusing messaging, but still be handled correctly as far as
passing along errors goes. E.g. if check_object_signature() returns
and oideq(real_oid, null_oid()) is true, which could happen if it
returns -1 due to the read_istream() call having failed.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-01 09:16:53 +00:00
|
|
|
struct object_id real_oid = *null_oid();
|
2021-10-01 09:16:52 +00:00
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
strbuf_reset(&cb_data->obj_type);
|
|
|
|
oi.type_name = &cb_data->obj_type;
|
|
|
|
oi.sizep = &size;
|
|
|
|
oi.typep = &type;
|
|
|
|
|
fsck: report invalid object type-path combinations
Improve the error that's emitted in cases where we find a loose object
we parse, but which isn't at the location we expect it to be.
Before this change we'd prefix the error with a not-a-OID derived from
the path at which the object was found, due to an emergent behavior in
how we'd end up with an "OID" in these codepaths.
Now we'll instead say what object we hashed, and what path it was
found at. Before this patch series e.g.:
$ git hash-object --stdin -w -t blob </dev/null
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ mv objects/e6/ objects/e7
Would emit ("[...]" used to abbreviate the OIDs):
git fsck
error: hash mismatch for ./objects/e7/9d[...] (expected e79d[...])
error: e79d[...]: object corrupt or missing: ./objects/e7/9d[...]
Now we'll instead emit:
error: e69d[...]: hash-path mismatch, found at: ./objects/e7/9d[...]
Furthermore, we'll do the right thing when the object type and its
location are bad. I.e. this case:
$ git hash-object --stdin -w -t garbage --literally </dev/null
8315a83d2acc4c174aed59430f9a9c4ed926440f
$ mv objects/83 objects/84
As noted in an earlier commits we'd simply die early in those cases,
until preceding commits fixed the hard die on invalid object type:
$ git fsck
fatal: invalid object type
Now we'll instead emit sensible error messages:
$ git fsck
error: 8315[...]: hash-path mismatch, found at: ./objects/84/15[...]
error: 8315[...]: object is of unknown type 'garbage': ./objects/84/15[...]
In both fsck.c and object-file.c we're using null_oid as a sentinel
value for checking whether we got far enough to be certain that the
issue was indeed this OID mismatch.
We need to add the "object corrupt or missing" special-case to deal
with cases where read_loose_object() will return an error before
completing check_object_signature(), e.g. if we have an error in
unpack_loose_rest() because we find garbage after the valid gzip
content:
$ git hash-object --stdin -w -t blob </dev/null
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ chmod 755 objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ echo garbage >>objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ git fsck
error: garbage at end of loose object 'e69d[...]'
error: unable to unpack contents of ./objects/e6/9d[...]
error: e69d[...]: object corrupt or missing: ./objects/e6/9d[...]
There is currently some weird messaging in the edge case when the two
are combined, i.e. because we're not explicitly passing along an error
state about this specific scenario from check_stream_oid() via
read_loose_object() we'll end up printing the null OID if an object is
of an unknown type *and* it can't be unpacked by zlib, e.g.:
$ git hash-object --stdin -w -t garbage --literally </dev/null
8315a83d2acc4c174aed59430f9a9c4ed926440f
$ chmod 755 objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
$ echo garbage >>objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
$ /usr/bin/git fsck
fatal: invalid object type
$ ~/g/git/git fsck
error: garbage at end of loose object '8315a83d2acc4c174aed59430f9a9c4ed926440f'
error: unable to unpack contents of ./objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
error: 8315a83d2acc4c174aed59430f9a9c4ed926440f: object corrupt or missing: ./objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
error: 0000000000000000000000000000000000000000: object is of unknown type 'garbage': ./objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
[...]
I think it's OK to leave that for future improvements, which would
involve enum-ifying more error state as we've done with "enum
unpack_loose_header_result" in preceding commits. In these
increasingly more obscure cases the worst that can happen is that
we'll get slightly nonsensical or inapplicable error messages.
There's other such potential edge cases, all of which might produce
some confusing messaging, but still be handled correctly as far as
passing along errors goes. E.g. if check_object_signature() returns
and oideq(real_oid, null_oid()) is true, which could happen if it
returns -1 due to the read_istream() call having failed.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-01 09:16:53 +00:00
|
|
|
if (read_loose_object(path, oid, &real_oid, &contents, &oi) < 0) {
|
|
|
|
if (contents && !oideq(&real_oid, oid))
|
|
|
|
err = error(_("%s: hash-path mismatch, found at: %s"),
|
|
|
|
oid_to_hex(&real_oid), path);
|
|
|
|
else
|
|
|
|
err = error(_("%s: object corrupt or missing: %s"),
|
|
|
|
oid_to_hex(oid), path);
|
|
|
|
}
|
2021-10-01 09:16:52 +00:00
|
|
|
if (type != OBJ_NONE && type < 0)
|
|
|
|
err = error(_("%s: object is of unknown type '%s': %s"),
|
fsck: report invalid object type-path combinations
Improve the error that's emitted in cases where we find a loose object
we parse, but which isn't at the location we expect it to be.
Before this change we'd prefix the error with a not-a-OID derived from
the path at which the object was found, due to an emergent behavior in
how we'd end up with an "OID" in these codepaths.
Now we'll instead say what object we hashed, and what path it was
found at. Before this patch series e.g.:
$ git hash-object --stdin -w -t blob </dev/null
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ mv objects/e6/ objects/e7
Would emit ("[...]" used to abbreviate the OIDs):
git fsck
error: hash mismatch for ./objects/e7/9d[...] (expected e79d[...])
error: e79d[...]: object corrupt or missing: ./objects/e7/9d[...]
Now we'll instead emit:
error: e69d[...]: hash-path mismatch, found at: ./objects/e7/9d[...]
Furthermore, we'll do the right thing when the object type and its
location are bad. I.e. this case:
$ git hash-object --stdin -w -t garbage --literally </dev/null
8315a83d2acc4c174aed59430f9a9c4ed926440f
$ mv objects/83 objects/84
As noted in an earlier commits we'd simply die early in those cases,
until preceding commits fixed the hard die on invalid object type:
$ git fsck
fatal: invalid object type
Now we'll instead emit sensible error messages:
$ git fsck
error: 8315[...]: hash-path mismatch, found at: ./objects/84/15[...]
error: 8315[...]: object is of unknown type 'garbage': ./objects/84/15[...]
In both fsck.c and object-file.c we're using null_oid as a sentinel
value for checking whether we got far enough to be certain that the
issue was indeed this OID mismatch.
We need to add the "object corrupt or missing" special-case to deal
with cases where read_loose_object() will return an error before
completing check_object_signature(), e.g. if we have an error in
unpack_loose_rest() because we find garbage after the valid gzip
content:
$ git hash-object --stdin -w -t blob </dev/null
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ chmod 755 objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ echo garbage >>objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
$ git fsck
error: garbage at end of loose object 'e69d[...]'
error: unable to unpack contents of ./objects/e6/9d[...]
error: e69d[...]: object corrupt or missing: ./objects/e6/9d[...]
There is currently some weird messaging in the edge case when the two
are combined, i.e. because we're not explicitly passing along an error
state about this specific scenario from check_stream_oid() via
read_loose_object() we'll end up printing the null OID if an object is
of an unknown type *and* it can't be unpacked by zlib, e.g.:
$ git hash-object --stdin -w -t garbage --literally </dev/null
8315a83d2acc4c174aed59430f9a9c4ed926440f
$ chmod 755 objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
$ echo garbage >>objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
$ /usr/bin/git fsck
fatal: invalid object type
$ ~/g/git/git fsck
error: garbage at end of loose object '8315a83d2acc4c174aed59430f9a9c4ed926440f'
error: unable to unpack contents of ./objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
error: 8315a83d2acc4c174aed59430f9a9c4ed926440f: object corrupt or missing: ./objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
error: 0000000000000000000000000000000000000000: object is of unknown type 'garbage': ./objects/83/15a83d2acc4c174aed59430f9a9c4ed926440f
[...]
I think it's OK to leave that for future improvements, which would
involve enum-ifying more error state as we've done with "enum
unpack_loose_header_result" in preceding commits. In these
increasingly more obscure cases the worst that can happen is that
we'll get slightly nonsensical or inapplicable error messages.
There's other such potential edge cases, all of which might produce
some confusing messaging, but still be handled correctly as far as
passing along errors goes. E.g. if check_object_signature() returns
and oideq(real_oid, null_oid()) is true, which could happen if it
returns -1 due to the read_istream() call having failed.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-01 09:16:53 +00:00
|
|
|
oid_to_hex(&real_oid), cb_data->obj_type.buf,
|
|
|
|
path);
|
2021-10-01 09:16:52 +00:00
|
|
|
if (err < 0) {
|
fsck: actually fsck blob data
Because fscking a blob has always been a noop, we didn't
bother passing around the blob data. In preparation for
content-level checks, let's fix up a few things:
1. The fsck_object() function just returns success for any
blob. Let's a noop fsck_blob(), which we can fill in
with actual logic later.
2. The fsck_loose() function in builtin/fsck.c
just threw away blob content after loading it. Let's
hold onto it until after we've called fsck_object().
The easiest way to do this is to just drop the
parse_loose_object() helper entirely. Incidentally,
this also fixes a memory leak: if we successfully
loaded the object data but did not parse it, we would
have left the function without freeing it.
3. When fsck_loose() loads the object data, it
does so with a custom read_loose_object() helper. This
function streams any blobs, regardless of size, under
the assumption that we're only checking the sha1.
Instead, let's actually load blobs smaller than
big_file_threshold, as the normal object-reading
code-paths would do. This lets us fsck small files, and
a NULL return is an indication that the blob was so big
that it needed to be streamed, and we can pass that
information along to fsck_blob().
Signed-off-by: Jeff King <peff@peff.net>
2018-05-02 19:44:51 +00:00
|
|
|
errors_found |= ERROR_OBJECT;
|
object-file: free(*contents) only in read_loose_object() caller
In the preceding commit a free() of uninitialized memory regression in
96e41f58fe1 (fsck: report invalid object type-path combinations,
2021-10-01) was fixed, but we'd still have an issue with leaking
memory from fsck_loose(). Let's fix that issue too.
That issue was introduced in my 31deb28f5e0 (fsck: don't hard die on
invalid object types, 2021-10-01). It can be reproduced under
SANITIZE=leak with the test I added in 093fffdfbec (fsck tests: add
test for fsck-ing an unknown type, 2021-10-01):
./t1450-fsck.sh --run=84 -vixd
In some sense it's not a problem, we lost the same amount of memory in
terms of things malloc'd and not free'd. It just moved from the "still
reachable" to "definitely lost" column in valgrind(1) nomenclature[1],
since we'd have die()'d before.
But now that we don't hard die() anymore in the library let's properly
free() it. Doing so makes this code much easier to follow, since we'll
now have one function owning the freeing of the "contents" variable,
not two.
For context on that memory management pattern the read_loose_object()
function was added in f6371f92104 (sha1_file: add read_loose_object()
function, 2017-01-13) and subsequently used in c68b489e564 (fsck:
parse loose object paths directly, 2017-01-13). The pattern of it
being the task of both sides to free() the memory has been there in
this form since its inception.
1. https://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-11 05:18:56 +00:00
|
|
|
free(contents);
|
fsck: actually fsck blob data
Because fscking a blob has always been a noop, we didn't
bother passing around the blob data. In preparation for
content-level checks, let's fix up a few things:
1. The fsck_object() function just returns success for any
blob. Let's a noop fsck_blob(), which we can fill in
with actual logic later.
2. The fsck_loose() function in builtin/fsck.c
just threw away blob content after loading it. Let's
hold onto it until after we've called fsck_object().
The easiest way to do this is to just drop the
parse_loose_object() helper entirely. Incidentally,
this also fixes a memory leak: if we successfully
loaded the object data but did not parse it, we would
have left the function without freeing it.
3. When fsck_loose() loads the object data, it
does so with a custom read_loose_object() helper. This
function streams any blobs, regardless of size, under
the assumption that we're only checking the sha1.
Instead, let's actually load blobs smaller than
big_file_threshold, as the normal object-reading
code-paths would do. This lets us fsck small files, and
a NULL return is an indication that the blob was so big
that it needed to be streamed, and we can pass that
information along to fsck_blob().
Signed-off-by: Jeff King <peff@peff.net>
2018-05-02 19:44:51 +00:00
|
|
|
return 0; /* keep checking other objects */
|
|
|
|
}
|
fsck: parse loose object paths directly
When we iterate over the list of loose objects to check, we
get the actual path of each object. But we then throw it
away and pass just the sha1 to fsck_sha1(), which will do a
fresh lookup. Usually it would find the same object, but it
may not if an object exists both as a loose and a packed
object. We may end up checking the packed object twice, and
never look at the loose one.
In practice this isn't too terrible, because if fsck doesn't
complain, it means you have at least one good copy. But
since the point of fsck is to look for corruption, we should
be thorough.
The new read_loose_object() interface can help us get the
data from disk, and then we replace parse_object() with
parse_object_buffer(). As a bonus, our error messages now
mention the path to a corrupted object, which should make it
easier to track down errors when they do happen.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 17:59:44 +00:00
|
|
|
|
|
|
|
if (!contents && type != OBJ_BLOB)
|
fsck: actually fsck blob data
Because fscking a blob has always been a noop, we didn't
bother passing around the blob data. In preparation for
content-level checks, let's fix up a few things:
1. The fsck_object() function just returns success for any
blob. Let's a noop fsck_blob(), which we can fill in
with actual logic later.
2. The fsck_loose() function in builtin/fsck.c
just threw away blob content after loading it. Let's
hold onto it until after we've called fsck_object().
The easiest way to do this is to just drop the
parse_loose_object() helper entirely. Incidentally,
this also fixes a memory leak: if we successfully
loaded the object data but did not parse it, we would
have left the function without freeing it.
3. When fsck_loose() loads the object data, it
does so with a custom read_loose_object() helper. This
function streams any blobs, regardless of size, under
the assumption that we're only checking the sha1.
Instead, let's actually load blobs smaller than
big_file_threshold, as the normal object-reading
code-paths would do. This lets us fsck small files, and
a NULL return is an indication that the blob was so big
that it needed to be streamed, and we can pass that
information along to fsck_blob().
Signed-off-by: Jeff King <peff@peff.net>
2018-05-02 19:44:51 +00:00
|
|
|
BUG("read_loose_object streamed a non-blob");
|
fsck: parse loose object paths directly
When we iterate over the list of loose objects to check, we
get the actual path of each object. But we then throw it
away and pass just the sha1 to fsck_sha1(), which will do a
fresh lookup. Usually it would find the same object, but it
may not if an object exists both as a loose and a packed
object. We may end up checking the packed object twice, and
never look at the loose one.
In practice this isn't too terrible, because if fsck doesn't
complain, it means you have at least one good copy. But
since the point of fsck is to look for corruption, we should
be thorough.
The new read_loose_object() interface can help us get the
data from disk, and then we replace parse_object() with
parse_object_buffer(). As a bonus, our error messages now
mention the path to a corrupted object, which should make it
easier to track down errors when they do happen.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 17:59:44 +00:00
|
|
|
|
2018-06-29 01:21:53 +00:00
|
|
|
obj = parse_object_buffer(the_repository, oid, type, size,
|
|
|
|
contents, &eaten);
|
|
|
|
|
fsck: parse loose object paths directly
When we iterate over the list of loose objects to check, we
get the actual path of each object. But we then throw it
away and pass just the sha1 to fsck_sha1(), which will do a
fresh lookup. Usually it would find the same object, but it
may not if an object exists both as a loose and a packed
object. We may end up checking the packed object twice, and
never look at the loose one.
In practice this isn't too terrible, because if fsck doesn't
complain, it means you have at least one good copy. But
since the point of fsck is to look for corruption, we should
be thorough.
The new read_loose_object() interface can help us get the
data from disk, and then we replace parse_object() with
parse_object_buffer(). As a bonus, our error messages now
mention the path to a corrupted object, which should make it
easier to track down errors when they do happen.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 17:59:44 +00:00
|
|
|
if (!obj) {
|
|
|
|
errors_found |= ERROR_OBJECT;
|
2018-11-10 05:16:15 +00:00
|
|
|
error(_("%s: object could not be parsed: %s"),
|
2017-02-21 23:47:35 +00:00
|
|
|
oid_to_hex(oid), path);
|
fsck: actually fsck blob data
Because fscking a blob has always been a noop, we didn't
bother passing around the blob data. In preparation for
content-level checks, let's fix up a few things:
1. The fsck_object() function just returns success for any
blob. Let's a noop fsck_blob(), which we can fill in
with actual logic later.
2. The fsck_loose() function in builtin/fsck.c
just threw away blob content after loading it. Let's
hold onto it until after we've called fsck_object().
The easiest way to do this is to just drop the
parse_loose_object() helper entirely. Incidentally,
this also fixes a memory leak: if we successfully
loaded the object data but did not parse it, we would
have left the function without freeing it.
3. When fsck_loose() loads the object data, it
does so with a custom read_loose_object() helper. This
function streams any blobs, regardless of size, under
the assumption that we're only checking the sha1.
Instead, let's actually load blobs smaller than
big_file_threshold, as the normal object-reading
code-paths would do. This lets us fsck small files, and
a NULL return is an indication that the blob was so big
that it needed to be streamed, and we can pass that
information along to fsck_blob().
Signed-off-by: Jeff King <peff@peff.net>
2018-05-02 19:44:51 +00:00
|
|
|
if (!eaten)
|
|
|
|
free(contents);
|
fsck: parse loose object paths directly
When we iterate over the list of loose objects to check, we
get the actual path of each object. But we then throw it
away and pass just the sha1 to fsck_sha1(), which will do a
fresh lookup. Usually it would find the same object, but it
may not if an object exists both as a loose and a packed
object. We may end up checking the packed object twice, and
never look at the loose one.
In practice this isn't too terrible, because if fsck doesn't
complain, it means you have at least one good copy. But
since the point of fsck is to look for corruption, we should
be thorough.
The new read_loose_object() interface can help us get the
data from disk, and then we replace parse_object() with
parse_object_buffer(). As a bonus, our error messages now
mention the path to a corrupted object, which should make it
easier to track down errors when they do happen.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 17:59:44 +00:00
|
|
|
return 0; /* keep checking other objects */
|
|
|
|
}
|
|
|
|
|
2017-07-20 00:21:44 +00:00
|
|
|
obj->flags &= ~(REACHABLE | SEEN);
|
|
|
|
obj->flags |= HAS_OBJ;
|
fsck: actually fsck blob data
Because fscking a blob has always been a noop, we didn't
bother passing around the blob data. In preparation for
content-level checks, let's fix up a few things:
1. The fsck_object() function just returns success for any
blob. Let's a noop fsck_blob(), which we can fill in
with actual logic later.
2. The fsck_loose() function in builtin/fsck.c
just threw away blob content after loading it. Let's
hold onto it until after we've called fsck_object().
The easiest way to do this is to just drop the
parse_loose_object() helper entirely. Incidentally,
this also fixes a memory leak: if we successfully
loaded the object data but did not parse it, we would
have left the function without freeing it.
3. When fsck_loose() loads the object data, it
does so with a custom read_loose_object() helper. This
function streams any blobs, regardless of size, under
the assumption that we're only checking the sha1.
Instead, let's actually load blobs smaller than
big_file_threshold, as the normal object-reading
code-paths would do. This lets us fsck small files, and
a NULL return is an indication that the blob was so big
that it needed to be streamed, and we can pass that
information along to fsck_blob().
Signed-off-by: Jeff King <peff@peff.net>
2018-05-02 19:44:51 +00:00
|
|
|
if (fsck_obj(obj, contents, size))
|
2015-09-24 21:08:33 +00:00
|
|
|
errors_found |= ERROR_OBJECT;
|
fsck: actually fsck blob data
Because fscking a blob has always been a noop, we didn't
bother passing around the blob data. In preparation for
content-level checks, let's fix up a few things:
1. The fsck_object() function just returns success for any
blob. Let's a noop fsck_blob(), which we can fill in
with actual logic later.
2. The fsck_loose() function in builtin/fsck.c
just threw away blob content after loading it. Let's
hold onto it until after we've called fsck_object().
The easiest way to do this is to just drop the
parse_loose_object() helper entirely. Incidentally,
this also fixes a memory leak: if we successfully
loaded the object data but did not parse it, we would
have left the function without freeing it.
3. When fsck_loose() loads the object data, it
does so with a custom read_loose_object() helper. This
function streams any blobs, regardless of size, under
the assumption that we're only checking the sha1.
Instead, let's actually load blobs smaller than
big_file_threshold, as the normal object-reading
code-paths would do. This lets us fsck small files, and
a NULL return is an indication that the blob was so big
that it needed to be streamed, and we can pass that
information along to fsck_blob().
Signed-off-by: Jeff King <peff@peff.net>
2018-05-02 19:44:51 +00:00
|
|
|
|
|
|
|
if (!eaten)
|
|
|
|
free(contents);
|
|
|
|
return 0; /* keep checking other objects, even if we saw an error */
|
2015-09-24 21:08:33 +00:00
|
|
|
}
|
|
|
|
|
2023-02-24 06:39:24 +00:00
|
|
|
static int fsck_cruft(const char *basename, const char *path,
|
|
|
|
void *data UNUSED)
|
2015-09-24 21:08:33 +00:00
|
|
|
{
|
|
|
|
if (!starts_with(basename, "tmp_obj_"))
|
2018-11-10 05:16:15 +00:00
|
|
|
fprintf_ln(stderr, _("bad sha1 file: %s"), path);
|
2015-09-24 21:08:33 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-02-24 06:39:24 +00:00
|
|
|
static int fsck_subdir(unsigned int nr, const char *path UNUSED, void *data)
|
2015-09-24 21:08:33 +00:00
|
|
|
{
|
2021-10-01 09:16:52 +00:00
|
|
|
struct for_each_loose_cb *cb_data = data;
|
|
|
|
struct progress *progress = cb_data->progress;
|
2015-09-24 21:08:33 +00:00
|
|
|
display_progress(progress, nr + 1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-06-28 21:58:33 +00:00
|
|
|
static void fsck_object_dir(const char *path)
|
|
|
|
{
|
2011-11-07 02:59:26 +00:00
|
|
|
struct progress *progress = NULL;
|
2021-10-01 09:16:52 +00:00
|
|
|
struct for_each_loose_cb cb_data = {
|
|
|
|
.obj_type = STRBUF_INIT,
|
|
|
|
.progress = progress,
|
|
|
|
};
|
2007-06-05 02:44:00 +00:00
|
|
|
|
|
|
|
if (verbose)
|
2018-11-10 05:16:15 +00:00
|
|
|
fprintf_ln(stderr, _("Checking object directory"));
|
2007-06-05 02:44:00 +00:00
|
|
|
|
2011-11-07 02:59:26 +00:00
|
|
|
if (show_progress)
|
2014-02-21 12:50:18 +00:00
|
|
|
progress = start_progress(_("Checking object directories"), 256);
|
2015-09-24 21:08:33 +00:00
|
|
|
|
|
|
|
for_each_loose_file_in_objdir(path, fsck_loose, fsck_cruft, fsck_subdir,
|
2021-10-01 09:16:52 +00:00
|
|
|
&cb_data);
|
2015-09-24 21:08:33 +00:00
|
|
|
display_progress(progress, 256);
|
2011-11-07 02:59:26 +00:00
|
|
|
stop_progress(&progress);
|
2021-10-01 09:16:52 +00:00
|
|
|
strbuf_release(&cb_data.obj_type);
|
2005-06-28 21:58:33 +00:00
|
|
|
}
|
|
|
|
|
2018-10-21 08:08:58 +00:00
|
|
|
static int fsck_head_link(const char *head_ref_name,
|
|
|
|
const char **head_points_at,
|
2018-10-21 08:08:57 +00:00
|
|
|
struct object_id *head_oid)
|
2005-07-03 17:40:38 +00:00
|
|
|
{
|
2007-04-11 08:28:43 +00:00
|
|
|
int null_is_error = 0;
|
|
|
|
|
2007-06-05 02:44:00 +00:00
|
|
|
if (verbose)
|
2019-01-04 21:33:31 +00:00
|
|
|
fprintf_ln(stderr, _("Checking %s link"), head_ref_name);
|
2007-06-05 02:44:00 +00:00
|
|
|
|
2018-10-21 08:08:58 +00:00
|
|
|
*head_points_at = resolve_ref_unsafe(head_ref_name, 0, head_oid, NULL);
|
2018-10-21 08:08:57 +00:00
|
|
|
if (!*head_points_at) {
|
2015-09-23 20:46:39 +00:00
|
|
|
errors_found |= ERROR_REFS;
|
2019-01-04 21:33:31 +00:00
|
|
|
return error(_("invalid %s"), head_ref_name);
|
2015-09-23 20:46:39 +00:00
|
|
|
}
|
2018-10-21 08:08:58 +00:00
|
|
|
if (!strcmp(*head_points_at, head_ref_name))
|
2007-04-11 08:28:43 +00:00
|
|
|
/* detached HEAD */
|
|
|
|
null_is_error = 1;
|
2018-10-21 08:08:57 +00:00
|
|
|
else if (!starts_with(*head_points_at, "refs/heads/")) {
|
2015-09-23 20:46:39 +00:00
|
|
|
errors_found |= ERROR_REFS;
|
2019-01-04 21:33:31 +00:00
|
|
|
return error(_("%s points to something strange (%s)"),
|
2018-10-21 08:08:58 +00:00
|
|
|
head_ref_name, *head_points_at);
|
2015-09-23 20:46:39 +00:00
|
|
|
}
|
2018-10-21 08:08:57 +00:00
|
|
|
if (is_null_oid(head_oid)) {
|
2015-09-23 20:46:39 +00:00
|
|
|
if (null_is_error) {
|
|
|
|
errors_found |= ERROR_REFS;
|
2019-01-04 21:33:31 +00:00
|
|
|
return error(_("%s: detached HEAD points at nothing"),
|
2018-10-21 08:08:58 +00:00
|
|
|
head_ref_name);
|
2015-09-23 20:46:39 +00:00
|
|
|
}
|
2019-01-04 21:33:31 +00:00
|
|
|
fprintf_ln(stderr,
|
|
|
|
_("notice: %s points to an unborn branch (%s)"),
|
|
|
|
head_ref_name, *head_points_at + 11);
|
2007-04-11 08:28:43 +00:00
|
|
|
}
|
2005-07-03 17:40:38 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-02-24 08:12:11 +00:00
|
|
|
static int fsck_cache_tree(struct cache_tree *it, const char *index_path)
|
2006-04-25 23:37:08 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int err = 0;
|
|
|
|
|
2007-06-05 02:44:00 +00:00
|
|
|
if (verbose)
|
2023-02-24 08:12:11 +00:00
|
|
|
fprintf_ln(stderr, _("Checking cache tree of %s"), index_path);
|
2007-06-05 02:44:00 +00:00
|
|
|
|
2006-04-25 23:37:08 +00:00
|
|
|
if (0 <= it->entry_count) {
|
2018-06-29 01:21:51 +00:00
|
|
|
struct object *obj = parse_object(the_repository, &it->oid);
|
2006-05-04 04:17:45 +00:00
|
|
|
if (!obj) {
|
2023-02-24 08:12:11 +00:00
|
|
|
error(_("%s: invalid sha1 pointer in cache-tree of %s"),
|
|
|
|
oid_to_hex(&it->oid), index_path);
|
2015-09-23 20:46:39 +00:00
|
|
|
errors_found |= ERROR_REFS;
|
2006-05-04 04:17:45 +00:00
|
|
|
return 1;
|
|
|
|
}
|
2017-07-20 00:21:44 +00:00
|
|
|
obj->flags |= USED;
|
2019-10-18 04:57:37 +00:00
|
|
|
fsck_put_object_name(&fsck_walk_options, &it->oid, ":");
|
2011-01-26 20:46:55 +00:00
|
|
|
mark_object_reachable(obj);
|
2006-07-12 03:45:31 +00:00
|
|
|
if (obj->type != OBJ_TREE)
|
2018-11-10 05:16:15 +00:00
|
|
|
err |= objerror(obj, _("non-tree in cache-tree"));
|
2006-04-25 23:37:08 +00:00
|
|
|
}
|
|
|
|
for (i = 0; i < it->subtree_nr; i++)
|
2023-02-24 08:12:11 +00:00
|
|
|
err |= fsck_cache_tree(it->down[i]->cache_tree, index_path);
|
2006-04-25 23:37:08 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2023-02-24 08:12:11 +00:00
|
|
|
static int fsck_resolve_undo(struct index_state *istate,
|
|
|
|
const char *index_path)
|
2022-06-09 23:44:20 +00:00
|
|
|
{
|
|
|
|
struct string_list_item *item;
|
|
|
|
struct string_list *resolve_undo = istate->resolve_undo;
|
|
|
|
|
|
|
|
if (!resolve_undo)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
for_each_string_list_item(item, resolve_undo) {
|
|
|
|
const char *path = item->string;
|
|
|
|
struct resolve_undo_info *ru = item->util;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!ru)
|
|
|
|
continue;
|
|
|
|
for (i = 0; i < 3; i++) {
|
|
|
|
struct object *obj;
|
|
|
|
|
|
|
|
if (!ru->mode[i] || !S_ISREG(ru->mode[i]))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
obj = parse_object(the_repository, &ru->oid[i]);
|
|
|
|
if (!obj) {
|
2023-02-24 08:12:11 +00:00
|
|
|
error(_("%s: invalid sha1 pointer in resolve-undo of %s"),
|
|
|
|
oid_to_hex(&ru->oid[i]),
|
|
|
|
index_path);
|
2022-06-09 23:44:20 +00:00
|
|
|
errors_found |= ERROR_REFS;
|
2022-07-11 23:25:14 +00:00
|
|
|
continue;
|
2022-06-09 23:44:20 +00:00
|
|
|
}
|
|
|
|
obj->flags |= USED;
|
|
|
|
fsck_put_object_name(&fsck_walk_options, &ru->oid[i],
|
|
|
|
":(%d):%s", i, path);
|
|
|
|
mark_object_reachable(obj);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-02-24 08:12:11 +00:00
|
|
|
static void fsck_index(struct index_state *istate, const char *index_path,
|
2023-06-29 18:13:33 +00:00
|
|
|
int is_current_worktree)
|
2023-02-24 08:07:32 +00:00
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
/* TODO: audit for interaction with sparse-index. */
|
|
|
|
ensure_full_index(istate);
|
|
|
|
for (i = 0; i < istate->cache_nr; i++) {
|
|
|
|
unsigned int mode;
|
|
|
|
struct blob *blob;
|
|
|
|
struct object *obj;
|
|
|
|
|
|
|
|
mode = istate->cache[i]->ce_mode;
|
|
|
|
if (S_ISGITLINK(mode))
|
|
|
|
continue;
|
|
|
|
blob = lookup_blob(the_repository,
|
|
|
|
&istate->cache[i]->oid);
|
|
|
|
if (!blob)
|
|
|
|
continue;
|
|
|
|
obj = &blob->object;
|
|
|
|
obj->flags |= USED;
|
|
|
|
fsck_put_object_name(&fsck_walk_options, &obj->oid,
|
2023-02-24 08:12:11 +00:00
|
|
|
"%s:%s",
|
2023-06-29 18:13:33 +00:00
|
|
|
is_current_worktree ? "" : index_path,
|
2023-02-24 08:12:11 +00:00
|
|
|
istate->cache[i]->name);
|
2023-02-24 08:07:32 +00:00
|
|
|
mark_object_reachable(obj);
|
|
|
|
}
|
|
|
|
if (istate->cache_tree)
|
2023-02-24 08:12:11 +00:00
|
|
|
fsck_cache_tree(istate->cache_tree, index_path);
|
|
|
|
fsck_resolve_undo(istate, index_path);
|
2023-02-24 08:07:32 +00:00
|
|
|
}
|
|
|
|
|
2017-02-21 23:47:35 +00:00
|
|
|
static void mark_object_for_connectivity(const struct object_id *oid)
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
{
|
2021-04-13 07:16:36 +00:00
|
|
|
struct object *obj = lookup_unknown_object(the_repository, oid);
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
obj->flags |= HAS_OBJ;
|
|
|
|
}
|
|
|
|
|
2017-02-21 23:47:35 +00:00
|
|
|
static int mark_loose_for_connectivity(const struct object_id *oid,
|
2023-02-24 06:39:24 +00:00
|
|
|
const char *path UNUSED,
|
|
|
|
void *data UNUSED)
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
{
|
2017-02-21 23:47:35 +00:00
|
|
|
mark_object_for_connectivity(oid);
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-02-21 23:47:35 +00:00
|
|
|
static int mark_packed_for_connectivity(const struct object_id *oid,
|
2023-02-24 06:39:24 +00:00
|
|
|
struct packed_git *pack UNUSED,
|
|
|
|
uint32_t pos UNUSED,
|
|
|
|
void *data UNUSED)
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
{
|
2017-02-21 23:47:35 +00:00
|
|
|
mark_object_for_connectivity(oid);
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-04-17 16:21:38 +00:00
|
|
|
static int check_pack_rev_indexes(struct repository *r, int show_progress)
|
|
|
|
{
|
|
|
|
struct progress *progress = NULL;
|
|
|
|
uint32_t pack_count = 0;
|
|
|
|
int res = 0;
|
|
|
|
|
|
|
|
if (show_progress) {
|
2023-05-02 13:27:22 +00:00
|
|
|
for (struct packed_git *p = get_all_packs(r); p; p = p->next)
|
2023-04-17 16:21:38 +00:00
|
|
|
pack_count++;
|
|
|
|
progress = start_delayed_progress("Verifying reverse pack-indexes", pack_count);
|
|
|
|
pack_count = 0;
|
|
|
|
}
|
|
|
|
|
2023-05-02 13:27:22 +00:00
|
|
|
for (struct packed_git *p = get_all_packs(r); p; p = p->next) {
|
2023-04-17 16:21:41 +00:00
|
|
|
int load_error = load_pack_revindex_from_disk(p);
|
|
|
|
|
|
|
|
if (load_error < 0) {
|
|
|
|
error(_("unable to load rev-index for pack '%s'"), p->pack_name);
|
|
|
|
res = ERROR_PACK_REV_INDEX;
|
|
|
|
} else if (!load_error &&
|
2023-05-02 13:27:22 +00:00
|
|
|
!load_pack_revindex(r, p) &&
|
2023-04-17 16:21:41 +00:00
|
|
|
verify_pack_revindex(p)) {
|
2023-04-17 16:21:38 +00:00
|
|
|
error(_("invalid rev-index for pack '%s'"), p->pack_name);
|
|
|
|
res = ERROR_PACK_REV_INDEX;
|
|
|
|
}
|
|
|
|
display_progress(progress, ++pack_count);
|
|
|
|
}
|
|
|
|
stop_progress(&progress);
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2007-10-15 20:34:05 +00:00
|
|
|
static char const * const fsck_usage[] = {
|
2022-10-13 15:39:18 +00:00
|
|
|
N_("git fsck [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]\n"
|
|
|
|
" [--[no-]full] [--strict] [--verbose] [--lost-found]\n"
|
|
|
|
" [--[no-]dangling] [--[no-]progress] [--connectivity-only]\n"
|
|
|
|
" [--[no-]name-objects] [<object>...]"),
|
2007-10-15 20:34:05 +00:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct option fsck_opts[] = {
|
2012-08-20 12:32:13 +00:00
|
|
|
OPT__VERBOSE(&verbose, N_("be verbose")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL(0, "unreachable", &show_unreachable, N_("show unreachable objects")),
|
2012-08-20 12:32:13 +00:00
|
|
|
OPT_BOOL(0, "dangling", &show_dangling, N_("show dangling objects")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL(0, "tags", &show_tags, N_("report tags")),
|
|
|
|
OPT_BOOL(0, "root", &show_root, N_("report root nodes")),
|
|
|
|
OPT_BOOL(0, "cache", &keep_cache_objects, N_("make index objects head nodes")),
|
|
|
|
OPT_BOOL(0, "reflogs", &include_reflogs, N_("make reflogs head nodes (default)")),
|
|
|
|
OPT_BOOL(0, "full", &check_full, N_("also consider packs and alternate objects")),
|
2015-06-22 15:27:12 +00:00
|
|
|
OPT_BOOL(0, "connectivity-only", &connectivity_only, N_("check only connectivity")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL(0, "strict", &check_strict, N_("enable more strict checking")),
|
|
|
|
OPT_BOOL(0, "lost-found", &write_lost_and_found,
|
2012-08-20 12:32:13 +00:00
|
|
|
N_("write dangling objects in .git/lost-found")),
|
|
|
|
OPT_BOOL(0, "progress", &show_progress, N_("show progress")),
|
2016-07-17 11:00:02 +00:00
|
|
|
OPT_BOOL(0, "name-objects", &name_objects, N_("show verbose names for reachable objects")),
|
2007-10-15 20:34:05 +00:00
|
|
|
OPT_END(),
|
|
|
|
};
|
2007-03-05 08:22:06 +00:00
|
|
|
|
2007-07-14 23:14:45 +00:00
|
|
|
int cmd_fsck(int argc, const char **argv, const char *prefix)
|
2005-04-08 22:02:42 +00:00
|
|
|
{
|
2017-07-26 01:34:56 +00:00
|
|
|
int i;
|
2018-11-12 14:48:47 +00:00
|
|
|
struct object_directory *odb;
|
2005-04-08 22:02:42 +00:00
|
|
|
|
2017-12-08 15:27:14 +00:00
|
|
|
/* fsck knows how to handle missing promisor objects */
|
|
|
|
fetch_if_missing = 0;
|
|
|
|
|
2007-03-05 08:22:06 +00:00
|
|
|
errors_found = 0;
|
2023-06-06 13:24:35 +00:00
|
|
|
disable_replace_refs();
|
fsck: turn off save_commit_buffer
When parsing a commit, the default behavior is to stuff the original
buffer into a commit_slab (which takes ownership of it). But for a tool
like fsck, this isn't useful. While we may look at the buffer further as
part of fsck_commit(), we'll always do so through a separate pointer;
attaching the buffer to the slab doesn't help.
Worse, it means we have to remember to free the commit buffer in all
call paths. We do so in fsck_obj(), which covers a regular "git fsck".
But with "--connectivity-only", we forget to do so in both
traverse_one_object(), which covers reachable objects, and
mark_unreachable_referents(), which covers unreachable ones. As a
result, that mode ends up storing an uncompressed copy of every commit
on the heap at once.
We could teach the code paths for --connectivity-only to also free
commit buffers. But there's an even easier fix: we can just turn off the
save_commit_buffer flag, and then we won't attach them to the commits in
the first place.
This reduces the peak heap of running "git fsck --connectivity-only" in
a clone of linux.git from ~2GB to ~1GB. According to massif, the
remaining memory goes where you'd expect: the object structs themselves,
the obj_hash containing them, and the delta base cache.
Note that we'll leave the call to free commit buffers in fsck_obj() for
now; it's not quite redundant because of a related bug that we'll fix in
a subsequent commit.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-09-22 10:13:36 +00:00
|
|
|
save_commit_buffer = 0;
|
2005-11-26 07:52:04 +00:00
|
|
|
|
2009-05-23 18:53:12 +00:00
|
|
|
argc = parse_options(argc, argv, prefix, fsck_opts, fsck_usage, 0);
|
2011-11-07 02:59:26 +00:00
|
|
|
|
2015-06-22 15:25:00 +00:00
|
|
|
fsck_walk_options.walk = mark_object;
|
|
|
|
fsck_obj_options.walk = mark_used;
|
|
|
|
fsck_obj_options.error_func = fsck_error_func;
|
|
|
|
if (check_strict)
|
|
|
|
fsck_obj_options.strict = 1;
|
|
|
|
|
2011-11-07 02:59:26 +00:00
|
|
|
if (show_progress == -1)
|
|
|
|
show_progress = isatty(2);
|
|
|
|
if (verbose)
|
|
|
|
show_progress = 0;
|
|
|
|
|
2007-10-15 20:34:05 +00:00
|
|
|
if (write_lost_and_found) {
|
|
|
|
check_full = 1;
|
|
|
|
include_reflogs = 0;
|
2005-04-25 23:31:13 +00:00
|
|
|
}
|
|
|
|
|
2016-07-17 11:00:02 +00:00
|
|
|
if (name_objects)
|
fsck: unify object-name code
Commit 90cf590f53 (fsck: optionally show more helpful info for broken
links, 2016-07-17) added a system for decorating objects with names. The
code is split across builtin/fsck.c (which gives the initial names) and
fsck.c (which adds to the names as it traverses the object graph). This
leads to some duplication, where both sites have near-identical
describe_object() functions (the difference being that the one in
builtin/fsck.c uses a circular array of buffers to allow multiple calls
in a single printf).
Let's provide a unified object_name API for fsck. That lets us drop the
duplication, as well as making the interface boundaries more clear
(which will let us refactor the implementation more in a future patch).
We'll leave describe_object() in builtin/fsck.c as a thin wrapper around
the new API, as it relies on a static global to make its many callers a
bit shorter.
We'll also convert the bare add_decoration() calls in builtin/fsck.c to
put_object_name(). This fixes two minor bugs:
1. We leak many small strings. add_decoration() has a last-one-wins
approach: it updates the decoration to the new string and returns
the old one. But we ignore the return value, leaking the old
string. This is quite common to trigger, since we look at reflogs:
the tip of any ref will be described both by looking at the actual
ref, as well as the latest reflog entry. So we'd always end up
leaking one of those strings.
2. The last-one-wins approach gives us lousy names. For instance, we
first look at all of the refs, and then all of the reflogs. So
rather than seeing "refs/heads/master", we're likely to overwrite
it with "HEAD@{12345678}". We're generally better off using the
first name we find.
And indeed, the test in t1450 expects this ugly HEAD@{} name. After
this patch, we've switched to using fsck_put_object_name()'s
first-one-wins semantics, and we output the more human-friendly
"refs/tags/julius" (and the test is updated accordingly).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18 04:56:13 +00:00
|
|
|
fsck_enable_object_names(&fsck_walk_options);
|
2016-07-17 11:00:02 +00:00
|
|
|
|
2021-03-17 18:20:36 +00:00
|
|
|
git_config(git_fsck_config, &fsck_obj_options);
|
2021-10-15 20:16:29 +00:00
|
|
|
prepare_repo_settings(the_repository);
|
2015-06-22 15:27:06 +00:00
|
|
|
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
if (connectivity_only) {
|
|
|
|
for_each_loose_object(mark_loose_for_connectivity, NULL, 0);
|
|
|
|
for_each_packed_object(mark_packed_for_connectivity, NULL, 0);
|
|
|
|
} else {
|
2018-03-23 17:21:07 +00:00
|
|
|
prepare_alt_odb(the_repository);
|
sha1-file: use an object_directory for the main object dir
Our handling of alternate object directories is needlessly different
from the main object directory. As a result, many places in the code
basically look like this:
do_something(r->objects->objdir);
for (odb = r->objects->alt_odb_list; odb; odb = odb->next)
do_something(odb->path);
That gets annoying when do_something() is non-trivial, and we've
resorted to gross hacks like creating fake alternates (see
find_short_object_filename()).
Instead, let's give each raw_object_store a unified list of
object_directory structs. The first will be the main store, and
everything after is an alternate. Very few callers even care about the
distinction, and can just loop over the whole list (and those who care
can just treat the first element differently).
A few observations:
- we don't need r->objects->objectdir anymore, and can just
mechanically convert that to r->objects->odb->path
- object_directory's path field needs to become a real pointer rather
than a FLEX_ARRAY, in order to fill it with expand_base_dir()
- we'll call prepare_alt_odb() earlier in many functions (i.e.,
outside of the loop). This may result in us calling it even when our
function would be satisfied looking only at the main odb.
But this doesn't matter in practice. It's not a very expensive
operation in the first place, and in the majority of cases it will
be a noop. We call it already (and cache its results) in
prepare_packed_git(), and we'll generally check packs before loose
objects. So essentially every program is going to call it
immediately once per program.
Arguably we should just prepare_alt_odb() immediately upon setting
up the repository's object directory, which would save us sprinkling
calls throughout the code base (and forgetting to do so has been a
source of subtle bugs in the past). But I've stopped short of that
here, since there are already a lot of other moving parts in this
patch.
- Most call sites just get shorter. The check_and_freshen() functions
are an exception, because they have entry points to handle local and
nonlocal directories separately.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-12 14:50:39 +00:00
|
|
|
for (odb = the_repository->objects->odb; odb; odb = odb->next)
|
2018-11-12 14:48:47 +00:00
|
|
|
fsck_object_dir(odb->path);
|
2009-01-30 08:50:54 +00:00
|
|
|
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
if (check_full) {
|
|
|
|
struct packed_git *p;
|
|
|
|
uint32_t total = 0, count = 0;
|
|
|
|
struct progress *progress = NULL;
|
2009-01-30 08:50:54 +00:00
|
|
|
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
if (show_progress) {
|
2018-08-20 16:52:04 +00:00
|
|
|
for (p = get_all_packs(the_repository); p;
|
2018-03-23 17:20:59 +00:00
|
|
|
p = p->next) {
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
if (open_pack_index(p))
|
|
|
|
continue;
|
|
|
|
total += p->num_objects;
|
|
|
|
}
|
2011-11-07 02:59:26 +00:00
|
|
|
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
progress = start_progress(_("Checking objects"), total);
|
|
|
|
}
|
2018-08-20 16:52:04 +00:00
|
|
|
for (p = get_all_packs(the_repository); p;
|
2018-03-23 17:20:59 +00:00
|
|
|
p = p->next) {
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
/* verify gives error messages itself */
|
2018-11-10 05:49:07 +00:00
|
|
|
if (verify_pack(the_repository,
|
|
|
|
p, fsck_obj_buffer,
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
progress, count))
|
|
|
|
errors_found |= ERROR_PACK;
|
|
|
|
count += p->num_objects;
|
2011-11-07 02:59:26 +00:00
|
|
|
}
|
fsck: prepare dummy objects for --connectivity-check
Normally fsck makes a pass over all objects to check their
integrity, and then follows up with a reachability check to
make sure we have all of the referenced objects (and to know
which ones are dangling). The latter checks for the HAS_OBJ
flag in obj->flags to see if we found the object in the
first pass.
Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`,
2015-06-22) taught fsck to skip the initial pass, and to
fallback to has_sha1_file() instead of the HAS_OBJ check.
However, it converted only one HAS_OBJ check to use
has_sha1_file(). But there are many other places in
builtin/fsck.c that assume that the flag is set (or that
lookup_object() will return an object at all). This leads to
several bugs with --connectivity-only:
1. mark_object() will not queue objects for examination,
so recursively following links from commits to trees,
etc, did nothing. I.e., we were checking the
reachability of hardly anything at all.
2. When a set of heads is given on the command-line, we
use lookup_object() to see if they exist. But without
the initial pass, we assume nothing exists.
3. When loading reflog entries, we do a similar
lookup_object() check, and complain that the reflog is
broken if the object doesn't exist in our hash.
So in short, --connectivity-only is broken pretty badly, and
will claim that your repository is fine when it's not.
Presumably nobody noticed for a few reasons.
One is that the embedded test does not actually test the
recursive nature of the reachability check. All of the
missing objects are still in the index, and we directly
check items from the index. This patch modifies the test to
delete the index, which shows off breakage (1).
Another is that --connectivity-only just skips the initial
pass for loose objects. So on a real repository, the packed
objects were still checked correctly. But on the flipside,
it means that "git fsck --connectivity-only" still checks
the sha1 of all of the packed objects, nullifying its
original purpose of being a faster git-fsck.
And of course the final problem is that the bug only shows
up when there _is_ corruption, which is rare. So anybody
running "git fsck --connectivity-only" proactively would
assume it was being thorough, when it was not.
One possibility for fixing this is to find all of the spots
that rely on HAS_OBJ and tweak them for the connectivity-only
case. But besides the risk that we might miss a spot (and I
found three already, corresponding to the three bugs above),
there are other parts of fsck that _can't_ work without a
full list of objects. E.g., the list of dangling objects.
Instead, let's make the connectivity-only case look more
like the normal case. Rather than skip the initial pass
completely, we'll do an abbreviated one that sets up the
HAS_OBJ flag for each object, without actually loading the
object data.
That's simple and fast, and we don't have to care about the
connectivity_only flag in the rest of the code at all.
While we're at it, let's make sure we treat loose and packed
objects the same (i.e., setting up dummy objects for both
and skipping the actual sha1 check). That makes the
connectivity-only check actually fast on a real repo (40
seconds versus 180 seconds on my copy of linux.git).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 21:32:57 +00:00
|
|
|
stop_progress(&progress);
|
2011-11-07 02:59:26 +00:00
|
|
|
}
|
2018-05-02 21:20:35 +00:00
|
|
|
|
|
|
|
if (fsck_finish(&fsck_obj_options))
|
|
|
|
errors_found |= ERROR_OBJECT;
|
2005-04-13 23:42:09 +00:00
|
|
|
}
|
|
|
|
|
2009-01-18 03:46:09 +00:00
|
|
|
for (i = 0; i < argc; i++) {
|
2007-06-07 07:04:01 +00:00
|
|
|
const char *arg = argv[i];
|
2017-07-13 23:49:18 +00:00
|
|
|
struct object_id oid;
|
2023-03-28 13:58:46 +00:00
|
|
|
if (!repo_get_oid(the_repository, arg, &oid)) {
|
2018-06-29 01:21:52 +00:00
|
|
|
struct object *obj = lookup_object(the_repository,
|
2019-06-20 07:41:14 +00:00
|
|
|
&oid);
|
2005-04-30 03:00:40 +00:00
|
|
|
|
2017-01-16 21:34:57 +00:00
|
|
|
if (!obj || !(obj->flags & HAS_OBJ)) {
|
2017-12-05 16:58:47 +00:00
|
|
|
if (is_promisor_object(&oid))
|
|
|
|
continue;
|
2018-11-10 05:16:15 +00:00
|
|
|
error(_("%s: object missing"), oid_to_hex(&oid));
|
2017-01-16 21:33:29 +00:00
|
|
|
errors_found |= ERROR_OBJECT;
|
2005-04-30 03:00:40 +00:00
|
|
|
continue;
|
2017-01-16 21:33:29 +00:00
|
|
|
}
|
2005-04-30 03:00:40 +00:00
|
|
|
|
2017-07-20 00:21:44 +00:00
|
|
|
obj->flags |= USED;
|
2019-10-18 04:57:37 +00:00
|
|
|
fsck_put_object_name(&fsck_walk_options, &oid,
|
fsck: unify object-name code
Commit 90cf590f53 (fsck: optionally show more helpful info for broken
links, 2016-07-17) added a system for decorating objects with names. The
code is split across builtin/fsck.c (which gives the initial names) and
fsck.c (which adds to the names as it traverses the object graph). This
leads to some duplication, where both sites have near-identical
describe_object() functions (the difference being that the one in
builtin/fsck.c uses a circular array of buffers to allow multiple calls
in a single printf).
Let's provide a unified object_name API for fsck. That lets us drop the
duplication, as well as making the interface boundaries more clear
(which will let us refactor the implementation more in a future patch).
We'll leave describe_object() in builtin/fsck.c as a thin wrapper around
the new API, as it relies on a static global to make its many callers a
bit shorter.
We'll also convert the bare add_decoration() calls in builtin/fsck.c to
put_object_name(). This fixes two minor bugs:
1. We leak many small strings. add_decoration() has a last-one-wins
approach: it updates the decoration to the new string and returns
the old one. But we ignore the return value, leaking the old
string. This is quite common to trigger, since we look at reflogs:
the tip of any ref will be described both by looking at the actual
ref, as well as the latest reflog entry. So we'd always end up
leaking one of those strings.
2. The last-one-wins approach gives us lousy names. For instance, we
first look at all of the refs, and then all of the reflogs. So
rather than seeing "refs/heads/master", we're likely to overwrite
it with "HEAD@{12345678}". We're generally better off using the
first name we find.
And indeed, the test in t1450 expects this ugly HEAD@{} name. After
this patch, we've switched to using fsck_put_object_name()'s
first-one-wins semantics, and we output the more human-friendly
"refs/tags/julius" (and the test is updated accordingly).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18 04:56:13 +00:00
|
|
|
"%s", arg);
|
2008-02-25 21:46:05 +00:00
|
|
|
mark_object_reachable(obj);
|
2005-04-13 16:57:30 +00:00
|
|
|
continue;
|
|
|
|
}
|
2018-11-10 05:16:15 +00:00
|
|
|
error(_("invalid parameter: expected sha1, got '%s'"), arg);
|
2017-01-16 21:33:29 +00:00
|
|
|
errors_found |= ERROR_OBJECT;
|
2005-04-13 16:57:30 +00:00
|
|
|
}
|
|
|
|
|
2005-05-18 17:16:14 +00:00
|
|
|
/*
|
2005-05-20 20:59:17 +00:00
|
|
|
* If we've not been given any explicit head information, do the
|
2005-05-18 17:19:59 +00:00
|
|
|
* default ones from .git/refs. We also consider the index file
|
|
|
|
* in this case (ie this implies --cache).
|
2005-05-18 17:16:14 +00:00
|
|
|
*/
|
2017-01-16 21:34:21 +00:00
|
|
|
if (!argc) {
|
2005-05-18 17:16:14 +00:00
|
|
|
get_default_heads();
|
|
|
|
keep_cache_objects = 1;
|
|
|
|
}
|
|
|
|
|
2005-05-04 08:33:33 +00:00
|
|
|
if (keep_cache_objects) {
|
2023-02-24 08:09:57 +00:00
|
|
|
struct worktree **worktrees, **p;
|
|
|
|
|
2017-04-14 20:32:21 +00:00
|
|
|
verify_index_checksum = 1;
|
2017-10-18 14:27:25 +00:00
|
|
|
verify_ce_order = 1;
|
2023-02-24 08:09:57 +00:00
|
|
|
|
|
|
|
worktrees = get_worktrees();
|
|
|
|
for (p = worktrees; *p; p++) {
|
|
|
|
struct worktree *wt = *p;
|
|
|
|
struct index_state istate =
|
|
|
|
INDEX_STATE_INIT(the_repository);
|
2023-02-24 08:12:11 +00:00
|
|
|
char *path;
|
2023-02-24 08:09:57 +00:00
|
|
|
|
2023-02-24 08:12:11 +00:00
|
|
|
/*
|
|
|
|
* Make a copy since the buffer is reusable
|
|
|
|
* and may get overwritten by other calls
|
|
|
|
* while we're examining the index.
|
|
|
|
*/
|
|
|
|
path = xstrdup(worktree_git_path(wt, "index"));
|
fsck: check even zero-entry index files
In fb64ca526a (fsck: check index files in all worktrees, 2023-02-24), we
swapped out a call to vanilla repo_read_index() for a series of
read_index_from() calls, one per worktree. The code for the latter was
copied from add_index_objects_to_pending(), which checks for a positive
return value from the index reading function, and we do the same here in
fsck now.
But this is probably the wrong thing. I had interpreted the check as
"don't operate on the index struct if there was an error". But in
reality, if there is an error then the index-reading code will simply
die (which admittedly is not great for fsck, but that is not a new
problem).
The return value here is actually the number of entries read. So it
makes sense for add_index_objects_to_pending() to ignore a zero-entry
index (there is nothing to add). But for fsck, we would still want to
check any extensions, etc (though presumably it is unlikely to have them
in an empty index, I don't think it's impossible).
So we should ignore the return value from read_index_from() entirely.
This matches the behavior before fb64ca526a, when we ignored the return
value from repo_read_index().
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-26 22:29:43 +00:00
|
|
|
read_index_from(&istate, path, get_worktree_git_dir(wt));
|
|
|
|
fsck_index(&istate, path, wt->is_current);
|
2023-02-24 08:09:57 +00:00
|
|
|
discard_index(&istate);
|
2023-02-24 08:12:11 +00:00
|
|
|
free(path);
|
2023-02-24 08:09:57 +00:00
|
|
|
}
|
|
|
|
free_worktrees(worktrees);
|
2005-05-04 08:33:33 +00:00
|
|
|
}
|
|
|
|
|
2023-04-17 16:21:38 +00:00
|
|
|
errors_found |= check_pack_rev_indexes(the_repository, show_progress);
|
fsck: verify checksums of all .bitmap files
If a filesystem-level corruption occurs in a .bitmap file, Git can react
poorly. This could take the form of a run-time error due to failing to
parse an EWAH bitmap or be more subtle such as returning the wrong set
of objects to a fetch or clone.
A natural first response to either of these kinds of errors is to run
'git fsck' to see if any files are corrupt. This currently ignores all
.bitmap files.
Add checks to 'git fsck' for all .bitmap files that are currently
associated with a multi-pack-index or pack file. Verify their checksums
using the hashfile API.
We iterate through all multi-pack-indexes and pack-files to be sure to
check all .bitmap files, not just the one that would be read by the
process. For example, a multi-pack-index bitmap overrules a pack-bitmap.
However, if the multi-pack-index is removed, the pack-bitmap may be
selected instead. Be thorough to include every file that could become
active in such a way. This includes checking files in alternates.
There is potential that we could extend this effort to check the
structure of the reachability bitmaps themselves, but it is very
expensive to do so. At minimum, it's as expensive as generating the
bitmaps in the first place, and that's assuming that we don't use the
trivial algorithm of verifying each bitmap individually. The trivial
algorithm will result in quadratic behavior (number of objects times
number of bitmapped commits) while the bitmap building operation
constructs a lattice of commits to build bitmaps incrementally and then
generate the final bitmaps from a subset of those commits.
If we were to extend 'git fsck' to check .bitmap file contents more
closely like this, then we would likely want to hide it behind an option
that signals the user is more willing to do expensive operations such as
this.
For testing, set up a repository with a pack-bitmap _and_ a
multi-pack-index bitmap. This requires some file movement to avoid
deleting the pack-bitmap during the repack that creates the
multi-pack-index bitmap. We can then verify that 'git fsck' is checking
all files, not just the "active" bitmap.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-02 13:27:21 +00:00
|
|
|
if (verify_bitmap_files(the_repository))
|
|
|
|
errors_found |= ERROR_BITMAP;
|
2023-04-17 16:21:38 +00:00
|
|
|
|
2005-04-11 06:13:09 +00:00
|
|
|
check_connectivity();
|
2018-06-27 13:24:43 +00:00
|
|
|
|
2021-10-15 20:16:29 +00:00
|
|
|
if (the_repository->settings.core_commit_graph) {
|
2018-06-27 13:24:43 +00:00
|
|
|
struct child_process commit_graph_verify = CHILD_PROCESS_INIT;
|
|
|
|
|
|
|
|
prepare_alt_odb(the_repository);
|
sha1-file: use an object_directory for the main object dir
Our handling of alternate object directories is needlessly different
from the main object directory. As a result, many places in the code
basically look like this:
do_something(r->objects->objdir);
for (odb = r->objects->alt_odb_list; odb; odb = odb->next)
do_something(odb->path);
That gets annoying when do_something() is non-trivial, and we've
resorted to gross hacks like creating fake alternates (see
find_short_object_filename()).
Instead, let's give each raw_object_store a unified list of
object_directory structs. The first will be the main store, and
everything after is an alternate. Very few callers even care about the
distinction, and can just loop over the whole list (and those who care
can just treat the first element differently).
A few observations:
- we don't need r->objects->objectdir anymore, and can just
mechanically convert that to r->objects->odb->path
- object_directory's path field needs to become a real pointer rather
than a FLEX_ARRAY, in order to fill it with expand_base_dir()
- we'll call prepare_alt_odb() earlier in many functions (i.e.,
outside of the loop). This may result in us calling it even when our
function would be satisfied looking only at the main odb.
But this doesn't matter in practice. It's not a very expensive
operation in the first place, and in the majority of cases it will
be a noop. We call it already (and cache its results) in
prepare_packed_git(), and we'll generally check packs before loose
objects. So essentially every program is going to call it
immediately once per program.
Arguably we should just prepare_alt_odb() immediately upon setting
up the repository's object directory, which would save us sprinkling
calls throughout the code base (and forgetting to do so has been a
source of subtle bugs in the past). But I've stopped short of that
here, since there are already a lot of other moving parts in this
patch.
- Most call sites just get shorter. The check_and_freshen() functions
are an exception, because they have entry points to handle local and
nonlocal directories separately.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-12 14:50:39 +00:00
|
|
|
for (odb = the_repository->objects->odb; odb; odb = odb->next) {
|
2018-11-12 14:46:54 +00:00
|
|
|
child_process_init(&commit_graph_verify);
|
|
|
|
commit_graph_verify.git_cmd = 1;
|
2021-11-25 22:52:20 +00:00
|
|
|
strvec_pushl(&commit_graph_verify.args, "commit-graph",
|
|
|
|
"verify", "--object-dir", odb->path, NULL);
|
fsck: suppress commit-graph output with `--no-progress`
Since e0fd51e1d7 (fsck: verify commit-graph, 2018-06-27), `fsck` runs
`git commit-graph verify` to check the integrity of any commit-graph(s).
Originally, the `git commit-graph verify` step would always print to
stdout/stderr, regardless of whether or not `fsck` was invoked with
`--[no-]progress` or not. But in 7371612255 (commit-graph: add
--[no-]progress to write and verify, 2019-08-26), the commit-graph
machinery learned the `--[no-]progress` option, though `fsck` was not
updated to pass this new flag (or not).
This led to seeing output from running `git fsck`, even with
`--no-progress` on repositories that have a commit-graph:
$ git.compile fsck --connectivity-only --no-progress --no-dangling
Verifying commits in commit graph: 100% (4356/4356), done.
Verifying commits in commit graph: 100% (131912/131912), done.
Ensure that `fsck` passes `--[no-]progress` as appropriate when calling
`git commit-graph verify`.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Acked-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-08 00:31:31 +00:00
|
|
|
if (show_progress)
|
|
|
|
strvec_push(&commit_graph_verify.args, "--progress");
|
|
|
|
else
|
|
|
|
strvec_push(&commit_graph_verify.args, "--no-progress");
|
2018-06-27 13:24:43 +00:00
|
|
|
if (run_command(&commit_graph_verify))
|
|
|
|
errors_found |= ERROR_COMMIT_GRAPH;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-10-15 20:16:30 +00:00
|
|
|
if (the_repository->settings.core_multi_pack_index) {
|
2018-09-13 18:02:27 +00:00
|
|
|
struct child_process midx_verify = CHILD_PROCESS_INIT;
|
|
|
|
|
|
|
|
prepare_alt_odb(the_repository);
|
sha1-file: use an object_directory for the main object dir
Our handling of alternate object directories is needlessly different
from the main object directory. As a result, many places in the code
basically look like this:
do_something(r->objects->objdir);
for (odb = r->objects->alt_odb_list; odb; odb = odb->next)
do_something(odb->path);
That gets annoying when do_something() is non-trivial, and we've
resorted to gross hacks like creating fake alternates (see
find_short_object_filename()).
Instead, let's give each raw_object_store a unified list of
object_directory structs. The first will be the main store, and
everything after is an alternate. Very few callers even care about the
distinction, and can just loop over the whole list (and those who care
can just treat the first element differently).
A few observations:
- we don't need r->objects->objectdir anymore, and can just
mechanically convert that to r->objects->odb->path
- object_directory's path field needs to become a real pointer rather
than a FLEX_ARRAY, in order to fill it with expand_base_dir()
- we'll call prepare_alt_odb() earlier in many functions (i.e.,
outside of the loop). This may result in us calling it even when our
function would be satisfied looking only at the main odb.
But this doesn't matter in practice. It's not a very expensive
operation in the first place, and in the majority of cases it will
be a noop. We call it already (and cache its results) in
prepare_packed_git(), and we'll generally check packs before loose
objects. So essentially every program is going to call it
immediately once per program.
Arguably we should just prepare_alt_odb() immediately upon setting
up the repository's object directory, which would save us sprinkling
calls throughout the code base (and forgetting to do so has been a
source of subtle bugs in the past). But I've stopped short of that
here, since there are already a lot of other moving parts in this
patch.
- Most call sites just get shorter. The check_and_freshen() functions
are an exception, because they have entry points to handle local and
nonlocal directories separately.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-12 14:50:39 +00:00
|
|
|
for (odb = the_repository->objects->odb; odb; odb = odb->next) {
|
2018-11-12 14:46:54 +00:00
|
|
|
child_process_init(&midx_verify);
|
|
|
|
midx_verify.git_cmd = 1;
|
2021-11-25 22:52:20 +00:00
|
|
|
strvec_pushl(&midx_verify.args, "multi-pack-index",
|
|
|
|
"verify", "--object-dir", odb->path, NULL);
|
fsck: suppress MIDX output with `--no-progress`
In a similar spirit as the previous commit, address a bug where `git
fsck` produces output when calling `git multi-pack-index verify` even
when invoked with `--no-progress`.
$ git.compile fsck --connectivity-only --no-progress --no-dangling
Verifying OID order in multi-pack-index: 100% (605677/605677), done.
Sorting objects by packfile: 100% (605678/605678), done.
Verifying object offsets: 100% (605678/605678), done.
The three lines produced by `git fsck` come from `git multi-pack-index
verify`, but should be squelched due to `--no-progress`.
The MIDX machinery learned to generate these progress messages as early
as 430efb8a74b (midx: add progress indicators in multi-pack-index
verify, 2019-03-21), but did not respect `--progress` or `--no-progress`
until ad60096d1c8 (midx: honor the MIDX_PROGRESS flag in
verify_midx_file, 2019-10-21).
But the `git multi-pack-index verify` step was added to fsck in
66ec0390e75 (fsck: verify multi-pack-index, 2018-09-13), pre-dating any
of the above patches.
Pass `--[no-]progress` as appropriate to ensure that we don't produce
output when told not to.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Acked-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-08 00:31:34 +00:00
|
|
|
if (show_progress)
|
|
|
|
strvec_push(&midx_verify.args, "--progress");
|
|
|
|
else
|
|
|
|
strvec_push(&midx_verify.args, "--no-progress");
|
2018-09-13 18:02:27 +00:00
|
|
|
if (run_command(&midx_verify))
|
2020-05-19 19:48:45 +00:00
|
|
|
errors_found |= ERROR_MULTI_PACK_INDEX;
|
2018-09-13 18:02:27 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-03-05 08:22:06 +00:00
|
|
|
return errors_found;
|
2005-04-08 22:02:42 +00:00
|
|
|
}
|