Re: Bug+bugfix in sftp-server : failed to rename file on sshfs mount
Johan Kielbaey wrote:[color=blue]
> 2008/11/5 Ben Lindstrom <email@example.com>:[color=green]
>> Without seeing the patch I can't judge it.
>> However, why is sshfs failure to implement things right an OpenSSH bug?[/color]
> 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
> 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.[/color]
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
> 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 [url]http://bugzilla.mindrot.org/[/url] 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[/color]
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.
openssh-unix-dev mailing list