[BUG] Teldrive driver does not preserve original file modification time on upload

[Scocers]

Please confirm the following

• I have read and agree to AGPL-3.0 Section 15 .
  The program is provided "as is" without any warranties; you bear all risks of using it.

• I have read and agree to AGPL-3.0 Section 16 .
  The copyright holders and distributors are not liable for any damages resulting from the use or inability to use the program.

• I confirm my description is clear, polite, helps developers quickly locate the issue, and complies with community rules.

• I have read the OpenList documentation.

• I confirm there are no duplicate issues or discussions.

• I confirm this is an OpenList issue, not caused by other reasons (such as network, dependencies, or operation).

• I believe this issue must be handled by OpenList and not by a third party.

• I confirm this issue is not fixed in the latest version.

• I have not read these checkboxes and therefore I just ticked them all, Please close this issue.

OpenList Version (required)

v4.2.3 (latest as of writing)

Storage Driver Used (required)

Teldrive

Bug Description (required)

Description

When uploading files to a Teldrive storage configured in OpenList, the modification time (mtime) reported for the file afterwards does not match the original file's modification time. Instead, it appears to reflect the time the upload/API call completed (i.e. the record creation time in Teldrive's backend), not the source file's actual mtime.

This causes the reported mtime to change on every re-upload/access, even when the file content is completely unchanged.

Steps to Reproduce

1. Add a storage in OpenList using the native Teldrive driver.
2. Upload a file with a known, fixed local modification time (e.g. an old file from 2015).
3. Check the file's modification time via OpenList (or via the Teldrive web UI / API GET /api/files/{id}).
4. Re-upload the same file (same content, same original mtime) at a later point in time, or simply re-check the listing after some time has passed.
5. Observe that the modification time returned differs each time / drifts forward, rather than staying fixed to the original file's mtime.

Expected Behavior

The modification time reported for a file in Teldrive (and thus surfaced via OpenList) should reflect the original file's mtime as provided by the client, and remain stable across repeated listings — not change based on when the upload/API request happened.

Actual Behavior

The modification time appears to reset to the upload/record-creation time, and can drift on subsequent operations, making it unreliable for any tool that relies on mtime for change detection (e.g. rsync-like sync tools, backup software).

Comparison / Additional Context

• When mounting Teldrive directly via a modified rclone remote (rclone mount teldrive: ...) and copying files onto it, the mtime is preserved correctly and remains stable across repeated Analyze/listing operations.
• The issue seems specific to OpenList's own Teldrive driver implementation, which talks to Teldrive's REST API independently of rclone's teldrive backend (see PR fix(drivers/teldrive): enhance file listing and upload functionality with pagination and random chunk naming #2034 "Enhance file listing and upload functionality with pagination and random chunk naming").
• Hypothesis: rclone's teldrive backend explicitly sends the source file's mtime as part of the upload/metadata request to Teldrive's API, while OpenList's driver may not be setting this field (or is setting it incorrectly), causing Teldrive's backend to fall back to LastModified/record creation time.

Impact

This makes Teldrive storages mounted/synced through OpenList unusable with any sync tool that compares files by size+modification time (e.g. GoodSync, rsync, Syncthing-style tools), since unchanged files are perpetually detected as "modified" and re-uploaded.

Environment

• OpenList version: v4.2.3 (latest as of writing)
• Driver: Teldrive (native)
• Backend: tgdrive/teldrive
• Comparison client: rclone (modified teldrive remote) — works correctly

Suggested Fix

Please check whether the Teldrive driver's upload implementation in OpenList explicitly sets/passes the source file's modification time to Teldrive's backend during upload (matching what the rclone teldrive backend does), so that mtime remains stable and accurate after upload.

Logs (required)

Logs not needed

Configuration File Content (required)

{
"openlist": {
"port": 5245,
"data_dir": "C:\Program Files (x86)\OpenList Desktop\data",
"binary_path": null,
"auto_launch": true,
"ssl_enabled": false
},
"rclone": {
"mount_config": {
"OpenL": {
"name": "OpenL",
"type": "webdav",
"url": "http://localhost:5245/dav",
"vendor": "other",
"user": "openlist_user",
"pass": "xxxxxxxxxx",
"mountPoint": "s:",
"volumeName": "/",
"extraFlags": [
"--vfs-cache-mode=full",
"--vfs-cache-max-age=5h",
"--vfs-cache-max-size=5G",
"--vfs-read-chunk-size=128M",
"--cache-dir "C:\rclone-cache2"",
"--links"
],
"autoMount": true
}
},
"binary_path": "C:\Program Files (x86)\OpenList Desktop\rclone.exe",
"rclone_conf_path": ""
},
"app": {
"theme": "dark",
"auto_update_enabled": true,
"gh_proxy": null,
"gh_proxy_api": false,
"open_links_in_browser": true,
"admin_password": "xxxxxxxxxxxxxxx",
"show_window_on_startup": false,
"log_filter_level": "all",
"log_filter_source": "rclone",
"hide_dock_icon": false
}
}

Reproduction Link (optional)

No response

AI Generated Content (optional)

No response

[jyxjjj]

The issue has been confirmed and will be addressed.

Additionally, this issue exhibits fairly obvious signs of AI-generated or AI-assisted writing, yet the AI Generated Content field is currently left blank. Please update it accordingly. If AI was used to generate, organize, refine, or translate any part of this issue, please disclose it truthfully.

[Scocers]

Bug found without using AI. I am not a native English speaker and used Claude AI only for translation and composing the bug report.