"Cannot sync due to invalid modification time"

[DAveShillito]

My Nextcloud Desktop Client just updated to the latest version (3.16.5 for Windows)
And I immediately saw the system tray icon change from the previous green tick to a red cross with the the error message:

"Some Files could not be synced"
and the reason given for these 2 files was
"Cannot sync due to invalid modification time"

The files were

"D:\<NextcloudPathOnMyPC>\InstantUpload\Screenshots\Screenshot_20211007-113843.png"
"D:\<NextcloudPathOnMyPC>\InstantUpload\Screenshots\Screenshot_20210211-161718.png"

As you can see these are files that have existed for 4 years and have never before reported as a problem. They are also now coincidently showing as 0 bytes in length - however I don’t know if this was always the case.

I am running Nextcloud Hub 9 (30.0.11)
This is just a small home server running on a Raspberry Pi 3 and has been running for years, although I noticed last week it was running version 28, which was not longer supported so I updated it to a more recent version.
The install was via NextcloudPi which is currently on version v1.55.4

Checking previous forum posts I found this error mentioned a number of times back in 2022, but nothing more recent.

The suggestion was to run a script solvable_files.sh and I just wanted to check if this was still a valid solution 3 years, and numerous Nextcloud versions later?

[DAveShillito]

I just checked an old backup I found from 2021.

And it appears those two files were showing as 0 bytes and dated 1970-01-01 back then.

So it does not look as though this is not a new problem with files being corrupted (which was my fear) but rather that the new sync client has noticed an issue that has been there for years and never caused an issue before.

Still my question is how can I fix it?

Is the solvable_files.sh script still valid?

Or can I just rename another image to match the names of the bad files and drop them over the top?

I did previously try deleting the files from both the web UI and in the synced folder on disk, but this did not remove the error, so I restored them from deleted items.

[DAveShillito]

I have now fixed this issue, so wanted to update this issue in case anyone else is affected by the same.

When I checked back on this post there was a banner present saying…

---

Desktop files client 3.16.5 known issue: slow remote discovery on the first run

In the previous versions the permissions reported by the server were not correctly taken into account. It would fail to detect read only files and it would try to download files without the download permission.

3.16.5 includes a fix for the handling of files permissions. The consequence of it is that the client will need to execute a full remote discovery during the first run to check for the correct permissions and update the files status accordingly. The discovery time might be slow depending on your server settings, on the number of folders and files and on the speed of the network between the client and the server.

The recommendation is still to upgrade to 3.16.5 because there are other bug fixes included in this version that might benefit you. In the meantime, we are working on improving the user experience on the first run.

---

Which explains why a historical error was only now being reported.

So I decided the easiest thing to do was to rename another image to match the names of the bad files and drop them over the top. I was then able to delete these files. I then deleted them permanently from the WebUI.

This removed the error on the sync client.