From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <junkio@cox.net>
Subject: Re: [PATCH] Fix merge-recursive on cygwin: broken errno when unlinking a directory
Date: Wed, 18 Apr 2007 16:04:06 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.0.98.0704181537590.9964@woody.linux-foundation.org> (raw)
In-Reply-To: <20070418223327.GC2477@steel.home>
On Thu, 19 Apr 2007, Alex Riesen wrote:
>
> + struct stat st;
> + int err = errno;
> + if (err == EISDIR ||
> + (err == EPERM && !lstat(path, &st) && S_ISDIR(st.st_mode))) {
Can I ask people to please *not* write things like this?
Here's an important rule from Linus:
Rule#1 when fixing bugs: there's a reason for the bug. And
_usually_ the reason was that the source code was hard to think
about or read.
So you should always make the source code more readable when you
fix a bug. If you don't, the bug will just reappear or is just
more subtly hidden! A bugfix that just makes the same code even
*harder* to read is not a fix at all!
(Side note: EPERM is actually apparently the POSIXLY correct error!)
Comlex conditionals are really just asking for bugs - either because they
are buggy themselves, or because people don't understand what they really
test for, and introduce bugs later.
That whole sequence should probably be a function of its own. But I'd also
like to note that for some strange and inexplicable reason, the regular
file handling and the symlink handling uses totally different setup, and
the symlink handling does *not* do any of the error checks that the file
case does.
So that function should be *common* to the two cases, and do the mkdir_p
_and_ the unlink. As it is, I suspect we have some test-case for regular
files that caused us to be careful with them, but we lack a test-case for
symlinks, so we never bothered to make the code work either!
So here's a suggested and totally untested patch. It makes the code more
readable, and probably fixes *two* bugs in the process. It also simply
doesn't really even care what the error actually was - the important part
was not that it was a directory, but that the unlink didn't succeed!
But even if somebody wants to re-introduce more errno value testing, I
think you should apply this patch *first*, because source code readability
really is very important!
Functions should be small and not have indentation of more than two
levels.
[ And yes, I realize I don't always follow my own rules, but I try. I
often don't write a hell of a lot of comments when I write the first
version of the code - I tend to add them later when some piece of code
has been shown to need them - but I try very hard to make functions
small and simple and do *one* thing, and not have lots of levels of
indentation. And if you see me write bad code, please flame me too! ]
Linus
---
merge-recursive.c | 54 ++++++++++++++++++++++++++++------------------------
1 files changed, 29 insertions(+), 25 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 595b022..cea6c87 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -574,6 +574,31 @@ static void flush_buffer(int fd, const char *buf, unsigned long size)
}
}
+static int make_room_for_path(const char *path)
+{
+ int status;
+ const char *msg = "failed to create path '%s'%s";
+
+ status = mkdir_p(path, 0777);
+ if (status) {
+ if (status == -3) {
+ /* something else exists */
+ error(msg, path, ": perhaps a D/F conflict?");
+ return -1;
+ }
+ die(msg, path, "");
+ }
+
+ /* Successful unlink is good.. */
+ if (!unlink(path))
+ return 0;
+ /* .. and so is no existing file */
+ if (errno == ENOENT)
+ return 0;
+ /* .. but not some other error (who really cares what?) */
+ return error(msg, path, ": perhaps a D/F conflict?");
+}
+
static void update_file_flags(const unsigned char *sha,
unsigned mode,
const char *path,
@@ -594,33 +619,12 @@ static void update_file_flags(const unsigned char *sha,
if (type != OBJ_BLOB)
die("blob expected for %s '%s'", sha1_to_hex(sha), path);
+ if (make_room_for_path(path) < 0) {
+ update_wd = 0;
+ goto update_index;
+ }
if (S_ISREG(mode) || (!has_symlinks && S_ISLNK(mode))) {
int fd;
- int status;
- const char *msg = "failed to create path '%s'%s";
-
- status = mkdir_p(path, 0777);
- if (status) {
- if (status == -3) {
- /* something else exists */
- error(msg, path, ": perhaps a D/F conflict?");
- update_wd = 0;
- goto update_index;
- }
- die(msg, path, "");
- }
- if (unlink(path)) {
- if (errno == EISDIR) {
- /* something else exists */
- error(msg, path, ": perhaps a D/F conflict?");
- update_wd = 0;
- goto update_index;
- }
- if (errno != ENOENT)
- die("failed to unlink %s "
- "in preparation to update: %s",
- path, strerror(errno));
- }
if (mode & 0100)
mode = 0777;
else
next prev parent reply other threads:[~2007-04-18 23:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-18 22:33 [PATCH] Fix merge-recursive on cygwin: broken errno when unlinking a directory Alex Riesen
2007-04-18 23:04 ` Linus Torvalds [this message]
2007-04-18 23:40 ` Alex Riesen
2007-04-19 8:28 ` Alex Riesen
2007-04-19 16:39 ` Linus Torvalds
2007-04-19 18:31 ` Sam Ravnborg
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=alpine.LFD.0.98.0704181537590.9964@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--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).