OneDrive client create many file versions when file modified time differ

[mayasd]

Hello,
I am not sure if it's a bug so that's why I started a discussion.

We recently identify that some files have many versions per day (+100). All these files are coming from SharePoint sites.
After investigation we find out than these files have different modified time on users computer

Below a data example of what we found on users computer (we just anonymize filename and user names):

# user1
$ echo 'select name,mtime from item where name like "%my_file.pdf%";' | sqlite3 ~/user1/.config/onedrive/items.sqlite3
my_file.pdf|2025-10-30T16:23:17Z

$ stat -c %y /home/user1/OneDrive/my_file.pdf
2025-10-30 17:23:17.000000000 +0100

# user2
$ echo 'select name,mtime from item where name like "%my_file.pdf%";' | sqlite3 ~/user2/.config/onedrive/items.sqlite3
my_file.pdf|2025-10-30T16:51:58Z

$ stat -c %y /home/user2/OneDrive/my_file.pdf
2025-10-30 17:51:58.000000000 +0100

# user3
$ echo 'select name,mtime from item where name like "%my_file.pdf%";' | sqlite3 ~/user3/.config/onedrive/items.sqlite3
my_file.pdf|2025-10-30T16:23:17Z

$ stat -c %y /home/user3/OneDrive/my_file.pdf
2025-10-30 17:51:58.000000000 +0100

As you can see, sometimes for a same user, local file modified date is different than database file modified date.

From OneDrive side we can see than each users create a new file version with different modified date:

OneDrive file version modified date corresponding to user local file modified date.

On OneDrive client logs we see these lines:

[2025-Nov-06 09:58:38.1787412] DEBUG: Attempting to calculate local filesystem path for 'b!Eg4Kf6jOVkusr3esqIPbzmFGsbPxkCtCnzET_EVKnjndd6mvXePQTpcaaI7rSK2G' and '01Z2RUIX4A7GYTVSOPXZA2Y5JTQFMLXJVK'
[2025-Nov-06 09:58:38.1789500] DEBUG: Calculated local path = MY_SHAREPOINT_SITE/my_file.pdf
[2025-Nov-06 09:58:38.1789689] DEBUG: Processing: MY_SHAREPOINT_SITE/my_file.pdf
[2025-Nov-06 09:58:38.1790074] DEBUG: Local file time discrepancy detected: MY_SHAREPOINT_SITE/my_file.pdf
[2025-Nov-06 09:58:38.1790528] DEBUG: This local file has a different modified time 2025-Oct-30 16:23:17Z (UTC) when compared to database modified time 2025-Oct-30 16:51:58Z (UTC)
[2025-Nov-06 09:58:38.1822635] DEBUG: The last modified timestamp has changed however the file content has not changed
[2025-Nov-06 09:58:38.1822816] DEBUG: The local item has the same hash value as the item online - correcting timestamp online
[2025-Nov-06 09:58:38.1823904] DEBUG: Read token from appConfig
[2025-Nov-06 09:58:38.1824038] DEBUG: Authorised State: true
[2025-Nov-06 09:58:38.1824293] DEBUG: HTTP patch request to URL: https://graph.microsoft.com/v1.0/drives/b!Eg4Kf6jOVkusr3esqIPbzmFGsbPxkCtCnzET_EVKnjndd6mvXePQTpcaaI7rSK2G/items/01Z2RUIX4A7GYTVSOPXZA2Y5JTQFMLXJVK

We don't know why and when users begin to have different local file modified date.
User configuration are the same:

--------------- Application Runtime Configuration ---------------
Application version                          = onedrive v2.5.7-1+np1+1.1
Compiled with                                = LDC 2106
Curl version                                 = libcurl/8.5.0 OpenSSL/3.0.13 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.2 (+libidn2/2.3.7) libssh/0.10.6/openssl/zlib nghttp2/1.59.0 librtmp/2.3 OpenLDAP/2.6.7
User Application Config path                 = /home/user1/.config/onedrive
System Application Config path               = /etc/onedrive
Applicable Application 'config' location     = /home/user1/.config/onedrive/config
Configuration file found in config location  = true - using 'config' file values to override application defaults
Applicable 'sync_list' location              = /home/user1/.config/onedrive/sync_list
Applicable 'items.sqlite3' location          = /home/user1/.config/onedrive/items.sqlite3
Config option 'drive_id'                     =
Config option 'sync_dir'                     = /home/user1/OneDrive
Config option 'use_intune_sso'               = false
Config option 'use_device_auth'              = false
Config option 'enable_logging'               = true
Config option 'log_dir'                      = /home/user1/.config/onedrive/logs
Config option 'disable_notifications'        = false
Config option 'skip_dir'                     =
Config option 'skip_dir_strict_match'        = false
Config option 'skip_file'                    = ~*|.~*|*.tmp|*.swp|*.partial
Config option 'skip_dotfiles'                = false
Config option 'skip_symlinks'                = false
Config option 'skip_size'                    = 0
Config option 'monitor_interval'             = 300
Config option 'monitor_log_frequency'        = 12
Config option 'monitor_fullscan_frequency'   = 12
Config option 'read_only_auth_scope'         = false
Config option 'dry_run'                      = false
Config option 'upload_only'                  = false
Config option 'download_only'                = false
Config option 'local_first'                  = false
Config option 'check_nosync'                 = false
Config option 'check_nomount'                = false
Config option 'resync'                       = false
Config option 'resync_auth'                  = false
Config option 'cleanup_local_files'          = false
Config option 'disable_permission_set'       = false
Config option 'transfer_order'               = default
Config option 'delay_inotify_processing'     = false
Config option 'inotify_delay'                = 5
Config option 'display_transfer_metrics'     = false
Config option 'force_session_upload'         = false
Config option 'file_fragment_size'           = 10
Config option 'classify_as_big_delete'       = 1000
Config option 'disable_upload_validation'    = false
Config option 'disable_download_validation'  = false
Config option 'bypass_data_preservation'     = false
Config option 'no_remote_delete'             = false
Config option 'remove_source_files'          = false
Config option 'sync_dir_permissions'         = 700
Config option 'sync_file_permissions'        = 600
Config option 'space_reservation'            = 52428800
Config option 'permanent_delete'             = false
Config option 'write_xattr_data'             = false
Config option 'create_new_file_version'      = false
Config option 'application_id'               = d50ca740-c83f-4d1b-b616-12c519384f0c
Config option 'azure_ad_endpoint'            =
Config option 'azure_tenant_id'              =
Config option 'user_agent'                   = ISV|abraunegg|OneDrive Client for Linux/v2.5.7-1+np1+1.1
Config option 'force_http_11'                = true
Config option 'debug_https'                  = false
Config option 'rate_limit'                   = 0
Config option 'operation_timeout'            = 3600
Config option 'dns_timeout'                  = 60
Config option 'connect_timeout'              = 10
Config option 'data_timeout'                 = 60
Config option 'ip_protocol_version'          = 0
Config option 'threads'                      = 8
Config option 'max_curl_idle'                = 120
Environment var 'XDG_RUNTIME_DIR'            = true
Environment var 'DBUS_SESSION_BUS_ADDRESS'   = true
Config option 'notify_file_actions'          = false
Config option 'use_recycle_bin'              = false
Config option 'recycle_bin_path'             = /home/user1/.local/share/Trash/

Selective sync 'sync_list' configured        = false

Config option 'sync_business_shared_items'   = true
Config option 'Shared Files Directory'       = /home/user1/OneDrive/Files Shared With Me

Config option 'webhook_enabled'              = false

--------------------DEVELOPER_OPTIONS----------------------------
Config option 'force_children_scan'          = false

• Is it possible to correcting timestamp online without create a new file version ?
• There is some workarounds for this problem ?

We think about erase all users local data (include OneDrive client local database) and start again.

Thank you

[abraunegg]

@mayasd

We recently identify that some files have many versions per day (+100). All these files are coming from SharePoint sites.
After investigation we find out than these files have different modified time on users computer
....
Is it possible to correcting timestamp online without create a new file version ?

When storing data on Microsoft SharePoint, Microsoft willfully changes your file, thus the online timestamp and hash is always being updated. This is a feature (bug) of Microsoft SharePoint that cannot be turned off.

The database stores the 'online' size as reported by the Microsoft Graph API. When a file is downloaded, this timestamp is used to set the timestamp of the local file so that:

• The timestamps are the same online and local
• The timestamp in the DB is accurate and correct

In your scenario:

• Local file has a timestamp of 2025-Oct-30 16:23:17Z (UTC)
• Online file has a timestamp of 2025-Oct-30 16:51:58Z (UTC) and is newer

What should be happening is:

1. If local timestamp is newer, change online
2. If local timestamp is older, change local

This is clearly not occurring, and defaulting to changing the online date. Because the online date is being changed, this is why a new version is being created.

When the application is being run, is --resync being used at all ? When using --resync you are blowing away all notion of what the correct state is and is a contributor to issues like this.

Additionally, file indexers (tracker, baloo and other) track that they have 'indexed' a file by modifying the local file timestamp to the timestamp that the file was indexed.

There is some workarounds for this problem ?

There is no work around for this issue - this appears to potentially be a logic issue.

We think about erase all users local data (include OneDrive client local database) and start again.

This will not solve your issue.

Next Steps

I would like to review a debug log if possible, or, if you can share reproduction steps I can see if I can replicate this.

To generate a debug log, create a new SharePoint site just for testing, and use dummy data, but keep all other environmental aspects the same. This will keep all sensitive data away, and only be pertinent to the test data / test SharePoint site.

Once I have reviewed a debug log, and this is a logic issue, a bug will need to be raised for tracking purposes.

[abraunegg]

@mayasd
I have reviewed the code, and I think this is a bug and I have also already identified a potential fix.

Please raise a bug report.

[mayasd]

Thank you. I created a new issue from this discussion #3521

[abraunegg]

Please open a bug report the correct way:

Please also do not close discussions.