process_rename assumes hard links?

[Corinna Vinschen]

Hi Damien,

On Oct 11 09:50, Damien Miller wrote:
> On Wed, 10 Oct 2012, Miguel Oliveira wrote:
> 
> > Hi,
> >
> > My name is Miguel Oliveira and I work at the University of Oslo
> > where we just deployed a new high performance compute cluster. Our
> > current parallel filesystem is FhGFS and we started having complaints
> > about problems with file transfers? We managed to diagnose this to
> > particular ssh clients that do not support the new posix rename
> > extension.
> >
> > Bottom line our filesystem does not support hard links and I think the
> > problem is that process_rename assumes link(old path,newpath) will
> > always return one. Shouldn't this situation, i.e., link returning a
> > symlink, be contemplated in the code?
> 
> link() shouldn't return a symlink(), it is a fundamentally different
> operation. It should return a hard link or errno=EOPNOTSUPP.

I just had a look into this piece of code, and due to this discussion
I realize that EPERM is not handled.  Linux as well as Cygwin return
EPERM if the underlying filesystem doesn't support hardlinks.  Any chance
to apply this patch?

Index: sftp-server.c
===================================================================
RCS file: /cvs/openssh/sftp-server.c,v
retrieving revision 1.111
diff -u -p -r1.111 sftp-server.c
--- sftp-server.c	20 Jun 2011 04:42:52 -0000	1.111
+++ sftp-server.c	11 Oct 2012 08:24:55 -0000
@@ -1079,6 +1079,7 @@ process_rename(void)
 		/* Race-free rename of regular files */
 		if (link(oldpath, newpath) == -1) {
 			if (errno == EOPNOTSUPP || errno == ENOSYS
+			    || errno == EPERM
 #ifdef EXDEV
 			    || errno == EXDEV
 #endif


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat