Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD

From: Jan Harkes <>
Date: 2005-10-27 02:15:52
On Wed, Oct 26, 2005 at 08:30:39AM -0700, Randal L. Schwartz wrote:
> >> >>>>> "Johannes" == Johannes Schindelin <> writes:
> Johannes> What does your man page for link() say? If it is not 
> Johannes> supported, what value will be in errno?
> >> 
> Interesting... google for "ENOTSUPP EOPNOTSUPP".  Apparently
> hits like this:
> <>
> shows that on some platforms, they may have both.  This is not as
> easy as it looks.  Maybe define an extra || condition to handle either
> or both?

It looks like glibc assumes that the kernel doesn't have ENOTSUP and
defines it as EOPNOTSUPP in <bits/errno.h>. So even if the kernel does
return different values, any glibc linked application probably wouldn't
be able to test for the ENOTSUP error.

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.

My local manual page for link(2) agrees with that definition,

	EPERM  oldpath is a directory.

	EPERM  The  filesystem  containing oldpath and newpath does not support
	       the creation of hard links.

I also took a look at the Linux 2.4/2.6 kernel sources, and msdos, fat
and vfat all do not set a function for 'dir->i_op->link'. In that case,
vfs_link() will return EPERM.

So I don't know where ENOTSUP/EOPNOTSUPP would be coming from. From the
few places I looked, I don't think the original patch can be right. Not
sure yet if I want to change Coda's return value to EPERM as well, the
thing is that we do support hardlinks, just not between different
directories, but I guess EXDEV isn't really accurate either.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at
Received on Thu Oct 27 02:16:26 2005

This archive was generated by hypermail 2.1.8 : 2005-10-27 02:16:29 EST