Bug+bugfix in sftp-server : failed to rename file on sshfs mount

[Darren Tucker]

Johan Kielbaey wrote:
> 2008/11/5 Ben Lindstrom <mouring at eviladmin.org>:
>> Without seeing the patch I can't judge it.
>>
>> However, why is sshfs failure to implement things right an OpenSSH bug?
> 
> Point taken. I guess I explained myself wrong. Obviously the fact that
> sshfs doesn't implement the link() call is not an OpenSSH bug. From my
> understanding the SFTPv3 protocol doesn't feature creation of hard
> links.
> 
> sftp-server falls back to the rename() syscall if the link() syscall
> fails with certain error codes. EOPNOTSUPP is such an errorcode. Sshfs
> however returns ENOSYS, which is not such as errorcode.

So on Linux, link(2) can return EPERM, EOPNOTSUPP or ENOSYS when it's 
not supported by the filesystem, depending on the filesystem?  Yay for 
consistency.

> Allowing a fall back to the rename() call upon ENOSYS errorcode,
> solves the issue for all filesystem that don't implement hard links.
> 
> An alternative solution would be to give preference to the rename()
> call over the link() call all the way. If you prefer I could work on a
> patch for that.
> 
>> BTW you may want to file it with http://bugzilla.mindrot.org/  so it doesn't
>> get lost as well (or at least skim the open and closed bugs on the rename()
>> and link() discussions.
>>
> 
> Done. Bug# 1535

I had not been following this thread so ignore my comment on the bug.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.