git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Glanzmann <thomas@glanzmann.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Do _not_ call unlink on a directory
Date: Tue, 17 Jul 2007 12:15:27 +0200	[thread overview]
Message-ID: <20070717101527.GB7774@cip.informatik.uni-erlangen.de> (raw)
In-Reply-To: <7vtzs3a0xg.fsf@assigned-by-dhcp.cox.net>

Hello Junio,

> This is wrong.  If the filesystem has a symlink and we would want a
> directory there, we should unlink().  So at least the stat there needs
> to be lstat().

I see.

> I wonder if anybody involved in the discussion has actually
> tested this patch (or the other one, that has the same problem)?

I tested it. But I did not test it with symlinks.

> Does the following replacement work for you?  It adds far more lines
> than your version, but they are mostly comments to make it clear why
> we do things this way.

Yes, it does. Excuse the delay but my build machine is not the fastest.

	(faui04a) [/var/tmp] git clone ~/work/repositories/public/easix.git test-10
	Initialized empty Git repository in /var/tmp/test-10/.git/
	remote: Generating pack...
	remote: Done counting 317 objects.
	remote: Deltifying 317 objects...
	remote: te: % (317/317) done: ) done
	Indexing 317 objects...
	remote: Total 317 (delta 182), reused 278 (delta 157)
	100% (317/317) done
	Resolving 182 deltas...
	100% (182/182) done
	(faui04a) [/var/tmp] cd test-10
	./test-10
	(faui04a) [/var/tmp/test-10] git status
	# On branch master
	nothing to commit (working directory clean)

I rebased your patch on top of current HEAD (as I can access it on
git.kernel.org) and removed trailing whitspace from one line (git-apply
complained)

	Thomas

>From 3b60b807007507ce5e1f8490f1469dac5bb95917 Mon Sep 17 00:00:00 2001
From: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
Date: Tue, 17 Jul 2007 11:31:07 +0200
Subject: [PATCH] Do _not_ call unlink on a directory

Calling unlink on a directory on a Solaris UFS filesystem as root makes it
inconsistent. Thanks to Junio for the not so obvious fix.
---
 entry.c |   37 ++++++++++++++++++++++++++++++-------
 1 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/entry.c b/entry.c
index c540ae1..0625112 100644
--- a/entry.c
+++ b/entry.c
@@ -8,17 +8,40 @@ static void create_directories(const char *path, const struct checkout *state)
 	const char *slash = path;
 
 	while ((slash = strchr(slash+1, '/')) != NULL) {
+		struct stat st;
+		int stat_status;
+
 		len = slash - path;
 		memcpy(buf, path, len);
 		buf[len] = 0;
+
+		if (len <= state->base_dir_len)
+			/*
+			 * checkout-index --prefix=<dir>; <dir> is
+			 * allowed to be a symlink to an existing
+			 * directory.
+			 */
+			stat_status = stat(buf, &st);
+		else
+			/*
+			 * if there currently is a symlink, we would
+			 * want to replace it with a real directory.
+			 */
+			stat_status = lstat(buf, &st);
+
+		if (!stat_status && S_ISDIR(st.st_mode))
+			continue; /* ok, it is already a directory. */
+
+		/*
+		 * We know stat_status == 0 means something exists
+		 * there and this mkdir would fail, but that is an
+		 * error codepath; we do not care, as we unlink and
+		 * mkdir again in such a case.
+		 */
 		if (mkdir(buf, 0777)) {
-			if (errno == EEXIST) {
-				struct stat st;
-				if (len > state->base_dir_len && state->force && !unlink(buf) && !mkdir(buf, 0777))
-					continue;
-				if (!stat(buf, &st) && S_ISDIR(st.st_mode))
-					continue; /* ok */
-			}
+			if (errno == EEXIST && state->force &&
+			    !unlink(buf) && !mkdir(buf, 0777))
+				continue;
 			die("cannot create directory at %s", buf);
 		}
 	}
-- 
1.5.2.1

  reply	other threads:[~2007-07-17 10:15 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-16 17:12 [PATCH] Do _not_ call unlink on a directory Thomas Glanzmann
2007-07-16 17:18 ` Matthieu Moy
2007-07-16 19:05   ` Scott Lamb
2007-07-16 19:56     ` Thomas Glanzmann
2007-07-16 20:00     ` Thomas Glanzmann
2007-07-16 20:21       ` Linus Torvalds
2007-07-16 20:25         ` Thomas Glanzmann
2007-07-16 20:34           ` Linus Torvalds
2007-07-16 20:39             ` Thomas Glanzmann
2007-07-16 21:23             ` Scott Lamb
2007-07-16 21:44               ` Linus Torvalds
2007-07-16 21:58                 ` Scott Lamb
2007-07-16 22:03                   ` Linus Torvalds
2007-07-16 20:29         ` Linus Torvalds
2007-07-16 17:38 ` Thomas Glanzmann
2007-07-16 17:41   ` Jan-Benedict Glaw
2007-07-16 17:42   ` Brian Downing
2007-07-16 17:55     ` Thomas Glanzmann
2007-07-16 19:58 ` Linus Torvalds
2007-07-16 21:06   ` Brian Downing
2007-07-16 21:19     ` Linus Torvalds
2007-07-17  8:58   ` David Kastrup
2007-07-17  7:30 ` Junio C Hamano
2007-07-17  8:28 ` Junio C Hamano
2007-07-17 10:15   ` Thomas Glanzmann [this message]
2007-07-17 18:34     ` Junio C Hamano
2007-07-17 20:27       ` Thomas Glanzmann
2007-07-18  7:24         ` Johannes Sixt
2007-07-18  8:50           ` Thomas Glanzmann
2007-07-17 19:07   ` Linus Torvalds

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=20070717101527.GB7774@cip.informatik.uni-erlangen.de \
    --to=thomas@glanzmann.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).