[Bug]: File creation date different between SFTP and Web upload

[dorbak]

⚠️ 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

When a file is uploaded via SFTP client (ie: Filezilla), the file uploaded will have the current date/time. However, when a file is uploaded via the web client, it will maintain the file's original create date/time.

Steps to reproduce

1. Find a file on your system that has been created some time ago
2. Upload via SFTP
3. Upload via WebUI
4. Compare the CreationTime of the file(s). SFTP will have the current time it was uploaded. WebUI will have the datetime of the original

Expected behavior

I would expect the either operation (WebUI or SFTP) to have the date/time of the upload operation.

Rationale: We have a 'cleanup' script that deletes files older than 2 weeks (amongst other activities). If a client uploads a file that was created earlier than 2 weeks but uploaded , it will get picked up by the script as a candidate for deletion.

Workaround we use:
I get the file's 'unix birth date' (stat -c <filename>) to get the actual linux creation date and compare that to determine whether a file should be deleted as part of the cleanup.

SFTPGo version

2.6.5

Data provider

mysql

Installation method

Community Docker image

Configuration

No changes made

Relevant log output

> ll

drwxr-xr-x  3 administrator administrator     4096 Sep 29 14:51 ./
drwxrwxr-x 39 administrator administrator     4096 Sep 29 16:09 ../
-rw-r--r--  1 administrator administrator 69292193 Sep 29 14:49 upload_via_sftp.txt
-rw-r--r--  1 administrator administrator 69292193 Apr  2 19:17 upload_via_webui.exe

=========

> stat -c '%W' upload_via_sftp.txt
1759157398
(Mon Sep 29 2025 14:49:58 GMT+0000)

=========

> stat -c '%W' upload_via_webui.exe
1759157496
(Mon Sep 29 2025 14:51:36 GMT+0000)

What are you using SFTPGo for?

Small business (3-person firm with file exchange?)

Additional info

Since we have a workaround, the criticality is low, but would be nice to not rely on this adjustment to identify files for deletion on our end.

Thanks!

Eric.