Bug 1535 - rename doesn't fall back to rename syscall upon ENOSYS of link syscall
Summary: rename doesn't fall back to rename syscall upon ENOSYS of link syscall
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sftp-server (show other bugs)
Version: 5.1p1
Hardware: ix86 Linux
: P3 normal
Assignee: Assigned to nobody
URL:
Keywords: patch
Depends on:
Blocks: V_5_3
  Show dependency treegraph
 
Reported: 2008-11-07 08:37 AEDT by Johan Kielbaey
Modified: 2009-10-06 15:01 AEDT (History)
3 users (show)

See Also:


Attachments
Patch fall back to rename() upon ENOSYS errorcode. (473 bytes, patch)
2008-11-07 08:38 AEDT, Johan Kielbaey
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Johan Kielbaey 2008-11-07 08:37:08 AEDT
Currently renaming of a file is implemented via a link() and unlink() syscall with the possibility to fall back to the rename() syscall in certain conditions (ENOTSUPP etc).

In case the errorcode returned by link() is ENOSYS this is not the case.

The attached patch implements a fallback to rename in case of ENOSYS.
Comment 1 Johan Kielbaey 2008-11-07 08:38:43 AEDT
Created attachment 1578 [details]
Patch fall back to rename() upon ENOSYS errorcode.
Comment 2 Darren Tucker 2008-11-07 09:22:16 AEDT
Sounds reasonable, but under what conditions does link return ENOSYS?  It's not documented in link(2) as a possible errno.
Comment 3 Damien Miller 2008-12-08 09:36:37 AEDT
We'd like this for openssh-5.2, but Darren's question needs an answer before we can commit it.
Comment 4 Darren Tucker 2008-12-09 11:39:57 AEDT
(In reply to comment #3)
> We'd like this for openssh-5.2, but Darren's question needs an answer
> before we can commit it.

Actually that was covered over on openssh-unix-dev: it's sshfs that returns ENOSYS.

http://marc.info/?l=openssh-unix-dev&m=122602218711487
Comment 5 Johan Kielbaey 2008-12-09 23:28:14 AEDT
(In reply to comment #4)
It was also brought to my attention on the mailinglist that the syscall link() shouldn't return ENOSYS. According to the link(2) the implementation of link in sshfs should return EPERM to indicate that creation of links is not supported. However the error check in sftp-server doesn't check EPERM either.

So actually the proper solution would be to fix this in sshfs and to add a fix in sftp-server to also check for EPERM.
Comment 6 Darren Tucker 2008-12-10 10:07:37 AEDT
(In reply to comment #5)
> (In reply to comment #4)
> It was also brought to my attention on the mailinglist that the syscall
> link() shouldn't return ENOSYS. According to the link(2) the
> implementation of link in sshfs should return EPERM to indicate that
> creation of links is not supported. However the error check in
> sftp-server doesn't check EPERM either.

Actually it does (on Linux, anyway):

                if (link(oldpath, newpath) == -1) {
                        if (errno == EOPNOTSUPP
#ifdef EXDEV
                            || errno == EXDEV
#endif
#ifdef LINK_OPNOTSUPP_ERRNO
                            || errno == LINK_OPNOTSUPP_ERRNO
#endif
                            ) {


where on Linux, LINK_OPNOTSUPP_ERRNO is defined thusly:
        AC_DEFINE(LINK_OPNOTSUPP_ERRNO, EPERM,
                [Define to whatever link() returns for "not supported"
                if it doesn't return EOPNOTSUPP.])
Comment 7 Damien Miller 2009-08-28 10:44:39 AEST
patch applied - this will be in openssh-5.3
Comment 8 Damien Miller 2009-10-06 15:01:59 AEDT
Mass move of RESOLVED bugs to CLOSED now that 5.3 is out.