Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD

From: Jan Harkes <jaharkes@cs.cmu.edu>
Date: Oct 26, 2005, 16:15 UTC
Message-ID: <20051026161552.GA11483@delft.aura.cs.cmu.edu>
In-Reply-To: <86irvkfg80.fsf@blue.stonehenge.com>

On Wed, Oct 26, 2005 at 08:30:39AM -0700, Randal L. Schwartz wrote:

Show 14 quoted lines

> >> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Johannes> What does your man page for link() say? If it is not 
> Johannes> supported, what value will be in errno?
> >> 
> >> EOPNOTSUPP
> 
> Interesting... google for "ENOTSUPP EOPNOTSUPP".  Apparently
> hits like this:
> 
> <http://sources.redhat.com/ml/bug-glibc/2002-08/msg00013.html>
> 
> 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.
    http://www.opengroup.org/onlinepubs/007908799/xsh/link.html

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.

Jan