From: Jonathan Nieder <jrnieder@gmail.com>
To: git@vger.kernel.org
Cc: gitster@pobox.com, "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
"Clemens Buchacher" <drizzd@aon.at>,
"Alex Riesen" <raa.lkml@gmail.com>
Subject: [PATCH 2/2] unpack-trees: handle lstat failure for existing file
Date: Wed, 12 Jan 2011 20:28:09 -0600 [thread overview]
Message-ID: <20110113022809.GC8635@burratino> (raw)
In-Reply-To: <20110113022415.GA8635@burratino>
When check_leading_path notices a file in the way of a new entry to be
checked out, verify_absent uses (1) the mode to determine whether it
is a directory (2) the rest of the stat information to check if this
is actually an old entry, disguised by a change in filename (e.g.,
README -> Readme) that is significant to git but insignificant to the
underlying filesystem. If lstat fails, these checks are performed
with an uninitialied stat structure, producing essentially random
results.
Better to just error out when lstat fails.
The easiest way to reproduce this is to remove a file after the
check_leading_path call and before the lstat in verify_absent. An
lstat failure other than ENOENT in check_leading_path would also
trigger the same code path.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
unpack-trees.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index a795db5..9c3fe64 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1374,7 +1374,9 @@ static int verify_absent_1(struct cache_entry *ce,
char path[PATH_MAX + 1];
memcpy(path, ce->name, len);
path[len] = 0;
- lstat(path, &st);
+ if (lstat(path, &st))
+ return error("cannot stat '%s': %s", path,
+ strerror(errno));
return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
error_type, o);
--
1.7.4.rc1
next prev parent reply other threads:[~2011-01-13 2:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-01 20:54 unpack-trees: fix D/F conflict bugs in verify_absent Clemens Buchacher
2009-01-01 20:54 ` [PATCH 1/3] unpack-trees: handle failure " Clemens Buchacher
2009-01-01 20:54 ` [PATCH 2/3] unpack-trees: fix path search bug " Clemens Buchacher
2009-01-01 20:54 ` [PATCH 3/3] unpack-trees: remove redundant path search " Clemens Buchacher
2009-01-06 8:19 ` Junio C Hamano
2009-01-02 21:59 ` [PATCH 2/3] unpack-trees: fix path search bug " Johannes Schindelin
2009-01-03 10:39 ` Clemens Buchacher
2009-01-03 12:53 ` Johannes Schindelin
2009-01-04 10:01 ` Junio C Hamano
2009-01-04 20:01 ` Clemens Buchacher
2009-01-06 19:35 ` Johannes Schindelin
2011-01-13 2:24 ` [RFC/PATCH 0/2] unpack-trees: handle lstat failures " Jonathan Nieder
2011-01-13 2:26 ` [PATCH 1/2] unpack-trees: handle lstat failure for existing directory Jonathan Nieder
2011-01-13 4:37 ` Miles Bader
2011-01-13 5:38 ` Jonathan Nieder
2011-01-13 2:28 ` Jonathan Nieder [this message]
2011-01-13 20:20 ` [RFC/PATCH 0/2] unpack-trees: handle lstat failures in verify_absent Clemens Buchacher
2009-01-01 21:28 ` unpack-trees: fix D/F conflict bugs " Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2008-12-16 23:24 Strange untracked file behaviour Miklos Vajna
2008-12-17 5:09 ` Johannes Schindelin
2008-12-17 14:38 ` Miklos Vajna
2009-01-02 21:59 ` [PATCH 2/3] unpack-trees: fix path search bug in verify_absent Johannes Schindelin
2009-01-03 14:01 ` Miklos Vajna
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110113022809.GC8635@burratino \
--to=jrnieder@gmail.com \
--cc=drizzd@aon.at \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=raa.lkml@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).