Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD

From: Jan Harkes <jaharkes@cs.cmu.edu>
Date: Oct 26, 2005, 16:55 UTC
Message-ID: <20051026165515.GA16616@delft.aura.cs.cmu.edu>
In-Reply-To: <20051026161552.GA11483@delft.aura.cs.cmu.edu>

On Wed, Oct 26, 2005 at 12:15:52PM -0400, Jan Harkes wrote:

> Checking the SuSv2 manpage for link(2), it doesn't mention either of
> these error codes. But does mention EPERM as a valid error when the
> filesystem doesn't support hardlinks.
>     http://www.opengroup.org/onlinepubs/007908799/xsh/link.html

Re-reading this, I seem to have misinterpreted the text. EPERM is returned when the filesystem doesn't allow hard linking a directory. I guess the closest error would actually be EMLINK, assuming that a filesystem that doesn't support hardlinks would have LINK_MAX set to 1.

    Linux returns EPERM
    Coda returns EXDEV
    BSDs seem to return EOPNOTSUPP.
    MacOS X/Darwin doesn't mention it in their manpages.

Simply falling back on rename when there is any error, as Linus suggested, seems like a pretty good solution right now. Rename should give the same set of errors except when the link target already existed.

Jan

diff --git a/sha1_file.c b/sha1_file.c
index e456799..0eba58c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1234,15 +1234,14 @@ int move_temp_to_file(const char *tmpfil
 	int ret = link_temp_to_file(tmpfile, filename);
 	if (ret) {
 		/*
-		 * Coda hack - coda doesn't like cross-directory links,
-		 * so we fall back to a rename, which will mean that it
-		 * won't be able to check collisions, but that's not a
-		 * big deal.
+		 * The file system may not support hardlinks, so we fall back
+		 * to a rename. We won't be able to check for collisions, but
+		 * that's not a big deal.
 		 *
 		 * When this succeeds, we just return 0. We have nothing
 		 * left to unlink.
 		 */
-		if (ret == EXDEV && !rename(tmpfile, filename))
+		if (ret && ret != EEXIST && !rename(tmpfile, filename))
 			return 0;
 	}
 	unlink(tmpfile);