summaryrefslogtreecommitdiff
path: root/fsck.c
AgeCommit message (Collapse)AuthorFilesLines
2014-03-31Merge branch 'hs/simplify-bit-setting-in-fsck-tree'Libravatar Junio C Hamano1-12/+6
* hs/simplify-bit-setting-in-fsck-tree: fsck: use bitwise-or assignment operator to set flag
2014-03-28Merge branch 'ys/fsck-commit-parsing'Libravatar Junio C Hamano1-12/+14
* ys/fsck-commit-parsing: fsck.c:fsck_commit(): use skip_prefix() to verify and skip constant fsck.c:fsck_ident(): ident points at a const string
2014-03-20fsck: use bitwise-or assignment operator to set flagLibravatar Hiroyuki Sano1-12/+6
fsck_tree() has two different ways to set a flag variable, either by using a if-statement that guards an assignment, or by using a bitwise-or assignment operator. Most are done with the former, and only one variable is assigned with the latter. Since all the conditions are short-and-sweet, we can afford to uniformly use the latter style, which makes the resulting code shorter and easier to read. Signed-off-by: Hiroyuki Sano <sh19910711@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-19fsck.c:fsck_commit(): use skip_prefix() to verify and skip constantLibravatar Yuxuan Shui1-11/+13
fsck_commit() uses memcmp() to check if the buffer starts with a certain prefix, and skips the prefix if it does. This is exactly what skip_prefix() was designed for. Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-13fsck.c:fsck_ident(): ident points at a const stringLibravatar Yuxuan Shui1-2/+2
Since fsck_ident doesn't change the content of **ident, the type of ident could be const char **. This change is required to rewrite fsck_commit() to use skip_prefix(). Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24date: check date overflow against time_tLibravatar Jeff King1-1/+1
When we check whether a timestamp has overflowed, we check only against ULONG_MAX, meaning that strtoul has overflowed. However, we also feed these timestamps to system functions like gmtime, which expect a time_t. On many systems, time_t is actually smaller than "unsigned long" (e.g., because it is signed), and we would overflow when using these functions. We don't know the actual size or signedness of time_t, but we can easily check for truncation with a simple assignment. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24fsck: report integer overflow in author timestampsLibravatar Jeff King1-6/+6
When we check commit objects, we complain if commit->date is ULONG_MAX, which is an indication that we saw integer overflow when parsing it. However, we do not do any check at all for author lines, which also contain a timestamp. Let's actually check the timestamps on each ident line with strtoul. This catches both author and committer lines, and we can get rid of the now-redundant commit->date check. Note that like the existing check, we compare only against ULONG_MAX. Now that we are calling strtoul at the site of the check, we could be slightly more careful and also check that errno is set to ERANGE. However, this will make further refactoring in future patches a little harder, and it doesn't really matter in practice. For 32-bit systems, one would have to create a commit at the exact wrong second in 2038. But by the time we get close to that, all systems will hopefully have moved to 64-bit (and if they haven't, they have a real problem one second later). For 64-bit systems, by the time we get close to ULONG_MAX, all systems will hopefully have been consumed in the fiery wrath of our expanding Sun. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28fsck: warn about ".git" in treesLibravatar Jeff King1-0/+5
Having a ".git" entry inside a tree can cause confusing results on checkout. At the top-level, you could not checkout such a tree, as it would complain about overwriting the real ".git" directory. In a subdirectory, you might check it out, but performing operations in the subdirectory would confusingly consider the in-tree ".git" directory as the repository. The regular git tools already make it hard to accidentally add such an entry to a tree, and do not allow such entries to enter the index at all. Teaching fsck about it provides an additional safety check, and let's us avoid propagating any such bogosity when transfer.fsckObjects is on. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28fsck: warn about '.' and '..' in treesLibravatar Jeff King1-0/+10
A tree with meta-paths like '.' or '..' does not work well with git; the index will refuse to load it or check it out to the filesystem (and even if we did not have that safety, it would look like we were overwriting an untracked directory). For the same reason, it is difficult to create such a tree with regular git. Let's warn about these dubious entries during fsck, just in case somebody has created a bogus tree (and this also lets us prevent them from propagating when transfer.fsckObjects is set). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-10Merge branch 'jk/maint-null-in-trees' into maint-1.7.11Libravatar Junio C Hamano1-1/+7
"git diff" had a confusion between taking data from a path in the working tree and taking data from an object that happens to have name 0{40} recorded in a tree. * jk/maint-null-in-trees: fsck: detect null sha1 in tree entries do not write null sha1s to on-disk index diff: do not use null sha1 as a sentinel value
2012-07-29fsck: detect null sha1 in tree entriesLibravatar Jeff King1-1/+7
Short of somebody happening to beat the 1 in 2^160 odds of actually generating content that hashes to the null sha1, we should never see this value in a tree entry. So let's have fsck warn if it it seen. As in the previous commit, we test both blob and submodule entries to future-proof the test suite against the implementation depending on connectivity to notice the error. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-30remove superfluous newlines in error messagesLibravatar Pete Wyckoff1-1/+1
The error handling routines add a newline. Remove the duplicate ones in error messages. Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11fsck: improve committer/author checkLibravatar Dmitry Ivankov1-4/+6
fsck allows a name with > character in it like "name> <email>". Also for "name email>" fsck says "missing space before email". More precisely, it seeks for a first '<', checks that ' ' preceeds it. Then seeks to '<' or '>' and checks that it is the '>'. Missing space is reported if either '<' is not found or it's not preceeded with ' '. Change it to following. Seek to '<' or '>', check that it is '<' and is preceeded with ' '. Seek to '<' or '>' and check that it is '>'. So now "name> <email>" is rejected as "bad name". More strict name check is the only change in what is accepted. Report 'missing space' only if '<' is found and is not preceeded with a space. Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-30Merge branch 'jm/maint-misc-fix' into maintLibravatar Junio C Hamano1-1/+1
* jm/maint-misc-fix: read_gitfile_gently: use ssize_t to hold read result remove tests of always-false condition rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
2011-05-26remove tests of always-false conditionLibravatar Jim Meyering1-1/+1
* fsck.c (fsck_error_function): Don't test obj->sha1 == 0. It can never be true, since that sha1 member is an array. * transport.c (set_upstreams): Likewise for ref->new_sha1. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-26strbuf: add strbuf_vaddfLibravatar Jeff King1-13/+1
In a variable-args function, the code for writing into a strbuf is non-trivial. We ended up cutting and pasting it in several places because there was no vprintf-style function for strbufs (which in turn was held up by a lack of va_copy). Now that we have a fallback va_copy, we can add strbuf_vaddf, the strbuf equivalent of vsprintf. And we can clean up the cut and paste mess. Signed-off-by: Jeff King <peff@peff.net> Improved-by: Christian Couder <christian.couder@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-28fsck: fix bogus commit header checkLibravatar Jonathan Nieder1-2/+0
daae1922 (fsck: check ident lines in commit objects, 2010-04-24) taught fsck to expect commit objects to have the form tree <object name> <parents> author <valid ident string> committer <valid ident string> log message The check is overly strict: for example, it errors out with the message “expected blank line” for perfectly valid commits with an "encoding ISO-8859-1" line. Later it might make sense to teach fsck about the rest of the header and warn about unrecognized header lines, but for simplicity, let’s accept arbitrary trailing lines for now. Reported-by: Tuncer Ayaz <tuncer.ayaz@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-01fsck: check ident lines in commit objectsLibravatar Jonathan Nieder1-0/+47
Check that email addresses do not contain <, >, or newline so they can be quickly scanned without trouble. The copy() function in ident.c already ensures that ordinary git commands will not write email addresses without this property. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-06Allow the Unix epoch to be a valid commit dateLibravatar Eric Wong1-1/+1
It is common practice to use the Unix epoch as a fallback date when a suitable date is not available. This is true of git svn and possibly other importing tools that import non-git history into git. Instead of clobbering established strtoul() error reporting semantics with our own, preserve the strtoul() error value of ULONG_MAX for fsck.c to handle. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-07Remove unused function scope local variablesLibravatar Benjamin Kramer1-5/+1
These variables were unused and can be removed safely: builtin-clone.c::cmd_clone(): use_local_hardlinks, use_separate_remote builtin-fetch-pack.c::find_common(): len builtin-remote.c::mv(): symref diff.c::show_stats():show_stats(): total diffcore-break.c::should_break(): base_size fast-import.c::validate_raw_date(): date, sign fsck.c::fsck_tree(): o_sha1, sha1 xdiff-interface.c::parse_num(): read_some Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-11Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Fix non-literal format in printf-style calls git-submodule: Avoid printing a spurious message. git ls-remote: make usage string match manpage Makefile: help people who run 'make check' by mistake
2008-11-11Fix non-literal format in printf-style callsLibravatar Daniel Lowe1-1/+1
These were found using gcc 4.3.2-1ubuntu11 with the warning: warning: format not a string literal and no format arguments Incorporated suggestions from Brandon Casey <casey@nrlssc.navy.mil>. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-12Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializerLibravatar Brandon Casey1-2/+1
Many call sites use strbuf_init(&foo, 0) to initialize local strbuf variable "foo" which has not been accessed since its declaration. These can be replaced with a static initialization using the STRBUF_INIT macro which is just as readable, saves a function call, and takes up fewer lines. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-03-05fsck.c: fix bogus "empty tree" checkLibravatar Junio C Hamano1-2/+0
ba002f3 (builtin-fsck: move common object checking code to fsck.c) did more than what it claimed to. Most notably, it wrongly made an empty tree object an error by pretending to only move code from fsck_tree() in builtin-fsck.c to fsck_tree() in fsck.c, but in fact adding a bogus check to barf on an empty tree. An empty tree object is _unusual_. Recent porcelains try reasonably hard not to let the user create a commit that contains such a tree. Perhaps warning about them in git-fsck may have some merit. HOWEVER. Being unusual and being errorneous are two quite different things. This is especially true now we seem to use the same fsck_$object() code in places other than git-fsck itself. For example, receive-pack should not reject unusual objects, even if it would be a good idea to tighten it to reject incorrect ones. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-25add common fsck error printing functionLibravatar Martin Koegler1-0/+29
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-25builtin-fsck: move common object checking code to fsck.cLibravatar Martin Koegler1-0/+215
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-25add generic, type aware object chain walkerLibravatar Martin Koegler1-0/+91
The requirements are: * it may not crash on NULL pointers * a callback function is needed, as index-pack/unpack-objects need to do different things * the type information is needed to check the expected <-> real type and print better error messages Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-01-29Make fsck and fsck-objects be builtins.Libravatar Mark Wooding1-690/+0
The earlier change df391b192 to rename fsck-objects to fsck broke fsck-objects. This should fix it again. Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28git-fsck-objects is now synonym to git-fsckLibravatar Junio C Hamano1-0/+690
Signed-off-by: Junio C Hamano <junkio@cox.net>