Bug 1535

Summary:

rename doesn't fall back to rename syscall upon ENOSYS of link syscall

Product:

Portable OpenSSH

Reporter:

Johan Kielbaey <johan.kielbaey>

Component:

sftp-server

Assignee:

Assigned to nobody <unassigned-bugs>

Status:

CLOSED FIXED

Severity:

normal

CC:

djm, dtucker, johan.kielbaey

Priority:

Keywords:

patch

Version:

5.1p1

Hardware:

ix86

OS:

Linux

Bug Depends on:

Bug Blocks:

1560

Attachments:

Description	Flags
Patch fall back to rename() upon ENOSYS errorcode.	none

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.