Looking for a solution to the above problem, I saw in CVSWeb that in current versions of OpenSSH, there is code in process_rename() in sftp-server.c which checks if links are available on the target filesystem. It does so by checking the errno given by link() against EOPNOTSUPP. The problem is: At least on Linux 2.6.x with glibc 2.3.5, link() returns EPERM in this case as is also documented in my copy of "man 2 link": ... EPERM oldpath is a directory. EPERM The filesystem containing oldpath and newpath does not support the creation of hard links. ... Thus the lack of link support is not detected and rename will not fall back to the stat/rename code. process_rename() fails even though it doesn't have to.
The code tests for LINK_OPNOTSUPP_ERRNO which is defined to be EPERM on Linux (in the Linux-specific block of configure). What happened when you actually tried it?
(In reply to comment #1) > The code tests for LINK_OPNOTSUPP_ERRNO which is defined to be EPERM on > Linux (in the Linux-specific block of configure). BTW that code has been there since version 3.9.
(In reply to comment #2) > (In reply to comment #1) > > The code tests for LINK_OPNOTSUPP_ERRNO which is defined to be EPERM on > > Linux (in the Linux-specific block of configure). > > BTW that code has been there since version 3.9. Ok, then sorry for bothering! I was trying to patch that piece of code into a 3.8p1 package for a Nokia 770 where obviously LINK_OPNOTSUPP_ERRNO won't be defined by configure. I'll just add that to the configure script too. Thanks!
Close resolved bugs after release.