[Bug]: SSH_FXP_RENAME overwrites existing file by default

[jsroest]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).

Bug description

If a file is renamed to a filename that already exists, the existing file is overwritten.

Steps to reproduce

1. upload a file 250919081509_Scans.csv with contents "version1".
2. upload a file 250919081509_Scans.tmp with contents "version2".
3. rename 250919081509_Scans.tmp to 250919081509_Scans.csv (with no flags configured)
4. observe that the contents of 250919081509_Scans.csv is now "version2".

Expected behavior

According the specifications, https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13:

If flags does not include SSH_FXP_RENAME_OVERWRITE, and there already exists a file with the name specified by newpath, the server MUST respond with SSH_FX_FILE_ALREADY_EXISTS.

I've compared this behaviour with another SFTP server (https://www.rebex.net/tiny-sftp-server/, and that returns "SftpStatusError: Already exists. (code 4).

SFTPGo version

2.6.6 6825db7

Data provider

sqlite

Installation method

Other

Configuration

I've made no customisations ("rename_mode": 0)

Relevant log output

{"level":"info","time":"2025-09-19T08:17:47.236","sender":"Rename","local_addr":"192.168.1.100:2022","remote_addr":"192.168.1.166:59790","username":"aswh","file_path":"/Users/johannesroest/sftpgo/aswh/250919081509_Scans.tmp","target_path":"/Users/johannesroest/sftpgo/aswh/250919081509_Scans.csv","filemode":"","uid":-1,"gid":-1,"access_time":"","modification_time":"","size":-1,"elapsed":0,"ssh_command":"","connection_id":"SFTP_296927a2436c73a94a267088a2b11a51f57757749cd6eaaf46ab1f5487b1bedb_1","protocol":"SFTP"}

What are you using SFTPGo for?

Medium business

Additional info

Installed with 'brew' on macOS. I use SFTPGO for development purposes.

[drakkan]

Hello, SFTPGo implements SFTPv3 as OpenSSH.
I believe our behavior in this case is consistent with v3 specs and OpenSSH

[jsroest]

Hi,
If I'm right, this page https://www.sftp.net/specification points me to the SFTPv3 specs https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-02.

Here it says:

Files (and directories) can be renamed using the SSH_FXP_RENAME message. Its data is as follows:
uint32 id
string oldpath
string newpath

It is an error if there already exists a file with the name specified by newpath.

[drakkan]

You're right, however, if you test with OpenSSH, you'll see that it behaves the same way as SFTPGo. I'll consider making this change in version 2.7.0, but it will need to be clearly documented, as it represents a significant behavior change and deviates from the de facto standard implementation. Thank you

[jsroest]

We use an upload, rename, delete-local strategy to be sure that the data has been sent in its entirety to the server. Checking if the file exists beforehand is not atomic and may lead to incidental dataloss for our solutions. Thank you for considering this change.

[drakkan]

We use an upload, rename, delete-local strategy to be sure that the data has been sent in its entirety to the server. Checking if the file exists beforehand is not atomic and may lead to incidental dataloss for our solutions. Thank you for considering this change.

SFTPGo needs to perform a stat operation internally regardless, so the process won't be atomic. This is because os.Rename replaces existing files, and I believe this is also why OpenSSH exhibits similar behavior

[jsroest]

Thanks for the insight on the 'stat' operation, I will look into that, if that affects our use case.

I just installed openSSH on Win11 from Settings > System > Optional features.
It also returns SftpStatusError: Failure(code 4) when I try to rename it to an existing file.

[drakkan]

Thanks for the insight on the 'stat' operation, I will look into that, if that affects our use case.

I just installed openSSH on Win11 from Settings > System > Optional features. It also returns SftpStatusError: Failure(code 4) when I try to rename it to an existing file.

Interesting. Could you please test against OpenSSH running on Linux or in a Docker container, and let us know the exact version used if an error occurs?

I have this using OpenSSH 10.0p1 on Linux

sftp> ls file*
file.txt         file1.txt        
sftp> rename file1.txt file.txt
sftp> ls file*
file.txt 

EDIT/NOTE: In my test, the SFTP CLI is using the posix-rename@openssh.com extension. Therefore, we should overwrite the file when this extension is used, and return an error otherwise. This is the correct behavior. I'll look into it further when I have some free time

[jsroest]

I can replicate the behaviour you describe exactly with the sftp executable from openSSH connecting to the openSSH instance on Win11.

I think the sftp> rename from openSSH has another implementation. Maybe with some flags added?

The code that I call sends the most simple version of the SSH_FXP_RENAME message:

SSH_FXP_RENAME
uint32 id
string oldpath
string newpath

  /// Renames a file or directory from [oldPath] to [newPath].
  Future<void> rename(String oldPath, String newPath) async {
    final reply = await _sendRename(oldPath, newPath);
    if (reply is! SftpStatusPacket) throw SftpError('Unexpected reply');
    SftpStatusError.check(reply);
  }

  Future<SftpResponsePacket> _sendRename(
    String oldPath,
    String newPath,
  ) async {
    await handshake;
    final request = SftpRenamePacket(_requestId.next, oldPath, newPath);
    _sendPacket(request);
    return await _waitReply(request.requestId);
  }

class SftpRenamePacket implements SftpRequestPacket {
  static const int packetType = 18;

  @override
  final int requestId;

  final String oldPath;

  final String newPath;

  SftpRenamePacket(this.requestId, this.oldPath, this.newPath);

  factory SftpRenamePacket.decode(Uint8List data) {
    final reader = SSHMessageReader(data);
    reader.readUint8(); // packet type
    final requestId = reader.readUint32();
    final oldPath = reader.readUtf8();
    final newPath = reader.readUtf8();
    return SftpRenamePacket(requestId, oldPath, newPath);
  }

  @override
  Uint8List encode() {
    final writer = SSHMessageWriter();
    writer.writeUint8(packetType);
    writer.writeUint32(requestId);
    writer.writeUtf8(oldPath);
    writer.writeUtf8(newPath);
    return writer.takeBytes();
  }

  @override
  String toString() {
    return 'SftpRenamePacket(requestId: $requestId, oldPath: $oldPath, newPath: $newPath)';
  }
}

  void _sendPacket(SftpPacket packet) {
    printTrace?.call('-> $_channel: $packet');
    final data = packet.encode();
    final writer = SSHMessageWriter();
    writer.writeUint32(data.length);
    writer.writeBytes(data);
    _channel.addData(writer.takeBytes());
  }

[drakkan]

I can replicate the behaviour you describe exactly with the sftp executable from openSSH connecting to the openSSH instance on Win11.

it uses posix-rename, see the above edit

[jsroest]

The posix rename is implemented as a SSH_FXP_EXTENDED request and that is only possible if the server advertises that it supports this extension. At least, according to info found here: https://www.sftp.net/spec/openssh-sftp-extensions.txt

I think the SSH_FXP_RENAME request is another, different kind of request, that should always be possible.

Let me know if I can help you in any way.

[drakkan]

Yes, see my edit above, the current behavior is correct when the client sends a posix-rename request. Otherwise, we should return an error.

There's no need for help at the moment. Even if you submit a PR, I’d still need to find the time to review it, and as you can see, I already have some pending PRs to review. I’ll add this to my TODO list as a low-priority task. Thanks for noticing