Desktop client 3.4.0 destroys local time stamp and keeps uploading data to server

I am also getting this “…has invalid time reported by server. Do not save it” warning for multiple files, every time I sync. That is based off a clean install of 3.4.1 (done yesterday), on a clean install of Windows 11 (done the day before).

The frustrating thing is that Nextcloud is giving me no information or guidance on what to do next. How can I save it or not save it? The error shows but I can have no further interaction with it.

2 Likes

Hi!
I’m also facing this huge issue. For me, this is a big issue, because we are now slowly implementing this in our company and I’m responsible for the project. So I really really hope this can be tackled soon!
If we can’t use the nextcloud client on windows, then we can’t use nextcloud at all!
Also the bash script didn’t give me any output at all, neither with list nor with fix argument!
Thanks!
Best regards!
Stefan

nextcloud-error
This is the error in my client. It keeps saying “invalid modification date don’t save”
Please provide a fix soon!
Thanks
Best regards!
Stefan

@stefanp2021 as you have commercial interest to fix the issue it would be great you spend little resources to help out people still affected by this issue. I think nice script could be written within 4-8 working hours…

Starting with SQL queries in my post #54 it’s possible to

  • build a list of files with invalid time stamp
  • find versions of this times with correct time stamp
  • build (a list) a command to copy/move the last valid version

running occ:filescan can remain manual task.

Hi,

@stefanp2021 if your nextlcoud setup isn’t on the same server where mysql is on. You must install a mysql client in first.

@mgallien for the single quote issues, here’s a solution:

relative_filepath_without_username="$(echo ${relative_filepath/\/$username\//} | sed "s/'/\\\'/g")"

Hi!

Nextcloud and SQL are on the same server!

Hi All,

I’ve seen the same on new installed NC client, trying to sync 100+ GB… I have 2 other PC’s syncing the same from the same account with “no” problems.

I’ve used the latest client 3.4.0

NC23, all on one server (Ubuntu 20.04LTS)

Thanks for any hints

roman

@rgischig Latest client version is v3.4.1

The group folder Script does not exist!
screenshot

Link giving 404 for reference:

https://raw.githubusercontent.com/nextcloud-gmbh/mtime_fixer_tool_kit/master/scanGroupFolders.sh

This contains the scripts and fixes, worked for me:

My guess the cause is a combo of Win11, NC Client 3.4.0 and/or 3.4.1 and the new Virtual Files function.

I have this issue too…so I disable the virtual file support.

For anyone getting errors like

ERROR:  syntax error at or near "base64"
LINE 4: ...mdzdGVjaG5pay9mdy1kdF9LYXBpdGVsMDhfMDFfMjAucGRm, 'base64'), ...
                                                             ^

(to my knowledge they occur when using pgsql and groupfolders) see SQL Error when using pgsql and groufolders · Issue #14 · nextcloud-gmbh/mtime_fixer_tool_kit · GitHub

Regards,
Tim

Is that proved or only a guess?
We had problems on several computers without Windows 11!

Removed all history (files and profiles) of the existing NC on the PC and reinstalled the latest version, . Now it works ok!

1 Like

Can somebody help me recover to a clean state so I can safely upgrade my Nextcloud + MariaDB?

I did use parts of the mtime fix scripts supplied here. One problem is the old MariaDB which has no FROM_BASE64 command.

So it looks like I do have

Folders which have more files locally than remotely. Mtime errors all over the place (3000+ files)
What I did manually now:

On the local (windows) machine in Ubuntu (WSL2):

find . -type f ! -newermt "@86400" -size +3c -exec touch -c -r ./testi.md {} \;

I also saved the file list just in case. These takes all files with at least 3 bytes and gave them a date from August 2020.

On the server I did the same but with current time.

I then did a occ files:scan and also the more important groupfolders:scan - it looks like you cannot call the group-folders scan with just one file path so it goes through everything.

I still do get some invalid modification times error on the latest sync and also the more worrying at least 350+ times:

Server hat "412 Precondition failed" auf "PUT https://SERVER/remote.php/dav/files/USER/PATH/file.ext" geantwortet (An If-Match header was specified, but none of the specified ETags matched.)

What is that error and how can I fix it.

P.S: Due to some bad architecture decisions I am still stuck at v20.0.6 - but before upgrading by migrating to an official Docker image I’d like to get this sync (only 3 windows clients) to safely execute…

For some reason Nextcloud GmbH decided not to help users with a real fix but just offered some half solutions as you mentioned above… additionally they added some dead-ends to the sync process like the “fix” to not replicate files with invalid timestamp, without offering a good way to fix such files…

at the end if you don’t have good backup to recover valid state you are limited to manually fix all the issues one by one before you continue… 350 files is a doable amount… nothing one appreciates but it could be done… as far I remember files with valid timestamp on the server have preference over files with invalid timestamp stored on the client - you could touchthe files, upload them into server file system and run occ file:scan… this should fix the issue at the cost of finally loosing mtime…

1 Like

I’m really leery now of this stuff, installed a fresh NC 23 and using the 3.4.1 client I don’t see stuff get synced reliably. I just don’t have anything specific to point at except “not all files get synced” which is not easy to pinpoint. However, never happened with earlier versions, so there’s that. I’m thrilled about not implementing NC in the company at least, that would have been bad with this level of reliability, potentially a bunch of users complaining of lost files, what a nightmare.

1 Like

Update: So far so good. I synced one of our 3 windows nextcloud clients

with my idea above, namely

  • manual find on server with all mtime error files
  • touch with current time for all these files
  • occ files scan and groupfolder scan

above it seems to have synced. Dont know if the find & mtime on the windows machine helped or not. Of course I lost the last modification time for all these 3000+ files, but if something were missing or newer on the client (and overwritten with server version) I see that it would show up in the activity log so I would be able to manually restore it from backups.

One directory did completely strike on sync. I deleted it and even had to copy it from backup & change the name on first sync. Afterwards I renamed it back to the original name and it worked.
my qnap documentaion word file I had open the whole time also had an irrecoverable conflict, so i deleted all, slightly renamed and re-uploaded it.

Now I am moving on to the second client …

BTW: 3.4.2 arrived yesterday: Releases · nextcloud/desktop · GitHub and also 23.0.1 with these commits:

23.0.1 is not offered via the updater yet, but you can find it here: https://download.nextcloud.com/server/releases/

This one is interesting: Prevent writing invalid mtime · nextcloud/server@36bacaa · GitHub