Issue with putfo and relative paths

[wrvdklooster]

I have an sftp server with the following directory structure:

/home/uploads

I have some code that uploads a file to this service using sftpretty as follows:

putfo(local_file, remotepath=uploads/uploadedfile.txt, confirm=True)

By default when connected I am in the /home directory.

With pysftp this used to work fine. With sftpretty behaviour changed it seems.

On one server this works fine. This server supports this:

debug2: Server supports extension "posix-rename@openssh.com" revision 1
debug2: Server supports extension "statvfs@openssh.com" revision 2
debug2: Server supports extension "fstatvfs@openssh.com" revision 2
debug2: Server supports extension "hardlink@openssh.com" revision 1
debug2: Server supports extension "fsync@openssh.com" revision 1
debug2: Server supports extension "lsetstat@openssh.com" revision 1
debug2: Server supports extension "limits@openssh.com" revision 1
debug2: Server supports extension "expand-path@openssh.com" revision 1
debug2: Server supports extension "copy-data" revision 1
debug2: Unrecognised server extension "home-directory"
debug2: Server supports extension "users-groups-by-id@openssh.com" revision 1

On another server this does not work. This server supports this:

debug2: Unrecognised server extension "versions"
debug2: Server supports extension "fsync@openssh.com" revision 1
debug2: Server supports extension "posix-rename@openssh.com" revision 1
debug2: Server supports extension "statvfs@openssh.com" revision 2
debug2: Server supports extension "fstatvfs@openssh.com" revision 2
debug2: Server supports extension "hardlink@openssh.com" revision 1
debug2: Unrecognised server extension "home-directory"

My guess would be the issue is with the missing expand-path@openssh.com support.

If I change the upload to using an absolute path it works fine on both:
putfo(local_file, remotepath=/home/uploads/uploadedfile.txt, confirm=True)

I am not sure if this is expected or if this is a bug.

The change I want to do on my side is to make the path absolute:

remote_path = self.client.normalize(remote_path)

[byteskeptical]

What version of Python3 are you running? Paramiko version? What OS (and version) are the servers and client? Do you see the same behavior with confirm=False? The rest of the debug log for both servers would be helpful (you can anonymize the IP/hostname and user if you'd like.

[wrvdklooster]

Environment:

• OS: OS-X 26.2 and Debian GNU/Linux 12 (same issue on both)
• Python 3.10.18
• sftpretty==1.1.10
• paramiko==4.0.0

With confirm=False it has the same issue.

Attached a trace log from the putfo call:

putfo_trace.txt

While checking it in Gemini it seems this is the issue (worked in pysftp somehow):

Look at this line in the trace: 12:53:13.29 .......... remotepath = 'orders/test'

And then the subsequent call: 12:53:13.29 >>> Call to SFTPClient._adjust_cwd: b'/orders/test'

The Issue: Because the server did not support expand-path, it couldn't handle the relative path orders/test. Paramiko tried to be helpful by "adjusting" it to /orders/test (the root), but since that directory didn't exist in the root, the server returned SFTP_NO_SUCH_FILE.

[byteskeptical]

Could you test with the #76 PR. I'm not sure expand-path itself is the issue as from what I've read it only handles ~ conversions. The new behavior normalizes the cwd on channel creation and chdir's to said working directory.

Another area of potential incompatibility relates to the use of remote
paths relative to other user's home directories, for example -
"scp host:~user/file /tmp". The SFTP protocol has no native way to
expand a ~user path. However, sftp-server(8) in OpenSSH 8.7 and later
support a protocol extension "expand-path@openssh.com" to support
this.

[wrvdklooster]

Looks good! I tested and this solved the issue I had.