When you modify something in a folder (let's say folder F), this folder changes it's modification time, but this new time doesn't propagate in the structure (the parent folder of F gets it's modification time untouched), at least when this date is in the future.
This leads to situations where it is very difficult to solve synchronization issues due to "invalid modification times": if there is a file with a date in the future all the whole folder tree downwards will get that date . The desktop client will stop syncing that branch of the structure folder due to "invalid modification time".
When you realize that problem with a file, you change it or touch to correct it's date, but the dates of the directories in that branch will remain in the future, preventing the client from syncing.
The way to solve it is either modify all that dates in the database, or going folder by folder downwards creating some file and deleting it, so that each folder get it's date updated. This can be a very very time consuming and prone to error in deep folder structures.
This may be related to the following issues, but not neccessarily: #4378, #4332
Steps to reproduce
Upload through webdav or web a file with a modification time in the future (say 2107-1-1) in a folder tree (say /A/B/C/file)
Wait for the client to sync that file. Will show "some files could not sync due to invalid modification time"
Touch that file to update it's modification date.
Run a file:scan so that it gets updated in the database
The folders (A, B, C) will remain with the date in the future, so the client will still fail to sync
Solve:
create a file in C and delete it through web: C will update its date but this will not be propagated to A and B
repeat 6 in B and A
Expected behavior
When you make a modification in the folder, this should be propagated to the date of the folders downwards in the database, if it is the most recent, but alwais if the current date for the folder is in the future.
Which files are affected by this bug
any
Operating system
Windows
Which version of the operating system you are running.
Windows 11
Package
Official Windows MSI
Nextcloud Server version
30.0.1
Nextcloud Desktop Client version
3.14.3
Is this bug present after an update or on a fresh install?
Updated to a major version (ex. 3.3.6 to 3.4.0)
Are you using the Nextcloud Server Encryption module?
areyal
commented
2 weeks ago
⚠️ Before submitting, please verify the following: ⚠️
Bug description
When you modify something in a folder (let's say folder F), this folder changes it's modification time, but this new time doesn't propagate in the structure (the parent folder of F gets it's modification time untouched), at least when this date is in the future. This leads to situations where it is very difficult to solve synchronization issues due to "invalid modification times": if there is a file with a date in the future all the whole folder tree downwards will get that date . The desktop client will stop syncing that branch of the structure folder due to "invalid modification time". When you realize that problem with a file, you change it or touch to correct it's date, but the dates of the directories in that branch will remain in the future, preventing the client from syncing.
The way to solve it is either modify all that dates in the database, or going folder by folder downwards creating some file and deleting it, so that each folder get it's date updated. This can be a very very time consuming and prone to error in deep folder structures.
This may be related to the following issues, but not neccessarily: #4378, #4332
Steps to reproduce
Expected behavior
When you make a modification in the folder, this should be propagated to the date of the folders downwards in the database, if it is the most recent, but alwais if the current date for the folder is in the future.
Which files are affected by this bug
any
Operating system
Windows
Which version of the operating system you are running.
Windows 11
Package
Official Windows MSI
Nextcloud Server version
30.0.1
Nextcloud Desktop Client version
3.14.3
Is this bug present after an update or on a fresh install?
Updated to a major version (ex. 3.3.6 to 3.4.0)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
Are you using an external user-backend?
Nextcloud Server logs
Additional info
This was tested in a Group Folder