3.4.0 keep synchronizing files after upgrade

[ghost]

Expected behaviour

Once updated from the 3.3.6 all my files started to resync all over again

Actual behaviour

Should not sync files that are already synced. I had to remove the folder and recreate it for the sync to stop

Steps to reproduce

1. Update to 3.4.0

Client configuration

Client version:

Operating system:
Windows 10
Windows 11
MacOS 12.0.1
OS language:
Eng
Client package (From Nextcloud or distro) (Linux only):
3.4.0

[valdearg]

Subscribing, also had this issue. Local stored files started syncing again as soon as the latest version was installed.

[ghost]

This happens on Macos also. I had to roll back to 3.3.6 i had alot of issues

[snandos]

Resync in terms of downloading or also uploading?
In my case (Windows 11 with virtual files) all my local files were uploaded again after the upgrade to 3.4.0 which resulted in a bunch of filechanges on the activity tab of Nextcloud.

[mgallien]

could you share your logs otherwise we cannot understand your problems

[ghost]

I'll have to try it on another computer and get you the longs

[snandos]

In the meantime I think i found out what my client was changing on the files on the serverside: The creation/modification date of the files - it was set to 0 -> 1970. And that on the other hand led to the creation year 2106 on the mac of my colleague (which is FFFF FFFF from 1970?!) - idk why. I think our clients never stopped syncing because of this?!

I'm currently fixing my two nextcloud instances, I hope I can search for the logs later.

Nextcloud version on the servers is 22.2.3 and 22.2.1

[MaxiMii05]

I can confirm that this is happening. Every creation date of every file in the sync folder was set to 1970 (basically 0). Because the client resyncs the entire file when metadata changes, it's now resyncing all of my files. Reinstalling version 3.3.6 didn't help as the metadata has already been changed.

I'm not sure how I am supposed to "fix" this. Is there any way to force-restore the previous versions of all files that now get replaced on the server and then force-resync all files from the server? I would very much appreciate if I didn't have to lose my metadata over this.

Edit: Removing and readding the folder synchronisation forces the client to redownload all (correct) files from the server instead of uploading the files with the wrong metadata. Still, files that have already been uploaded to the server with wrong metadata stay that way. It's too much of a hassle to manually restore the previous version for the hundreds of files that have been changed, so I'm just going to give up on that.

[ghost]

I would use https://www.revouninstaller.com/revo-uninstaller-free-download/ to uninstall and it also dose a registry remove off the app and any files and folders associated with it then reboot, reinstall the 3.3.6 client

[ghost]

It chanaged all file files create date back to year 1970 I don't think this is a very good idea to keep this still activate as it changes users data

[valdearg]

Probably a good idea to pull this update until this is resolved if it's causing these issues.

[ghost]

Yes i think so too.. i'm remove this from all my computers.

[edmael]

Same issue here: all dates are set to 1970.
OS: Windows 11
Nextcloud client version: 3.4.0

[robertofabrizi]

The fact that this update got out to the public with such a major bug is completely unacceptable, please remove it immediately before more and more people end up with a mess

[ruffy91]

Same issue here on Windows 11 22000.348
All files and folders show all file dates (created, last modified,) as 1.1.1970.

We had to restore the Nextcloud server from backup to get rid of the newly synced files.

Is it possible to block the 3.4.0 client from connecting to the server?

I use the virtual file sync on the clients.

Edit: NC Server is on version 22.2.3

[ghost]

I think you can setup in the config what client my Version you want to allow check out out the admin doc

[mikhail5555]

An extra two cents to the effect this problem had. It invalided the meta-data of about 40gb of pictures which i kept synced on my desktop.

Maybe if such a big change happens it would be very nice to have an confirmation in the nextcloud client asking you 'if you are sure you want to submit 40gb worth of changes to the server'.

About the same with the confirmation of if you want to sync a file bigger than xxx from the server to your local machine.

Edit: I am very happy i make nightly local backups. However after this i might disable the 'auto-update' feature of the nextcloud client until some steps are taken to prevent this kind of behavior in the future.

[ghost]

I really hope they pull this update. As it may cause a lot of issues for Nextcloud enterprise clients.

[mikhail5555]

I would use https://www.revouninstaller.com/revo-uninstaller-free-download/ to uninstall and it also dose a registry remove off the app and any files and folders associated with it then reboot, reinstall the 3.3.6 client

Indeed be sure you remove all 'locally synced' files, files which were only enabled as virtual files are unaffected.

[Githopp192]

same to me .. did the upgrade from previous version on Windows 10. Then i noticed that after restarting the new agent 3.4 - that the agent 3.4 started to sync a lot of data, which were already synced before. Also, some applications will report errors now (like Cookbook ... reporting, that some recipes have spaces at the end, but i know, i did correct this one month before, so i suppose there can be some data inconsistencies into the data already).

When i have a look (as example) to files & folder in the cookbook "recipes" folder on Windows i do count:
1’476 files , 305 directories

when i do the same by Linux:

find . -type d | wc -l ==> 344 directories
find . -type f | wc -l ==> 1663 files

and indeed on Windows 10 a lot of files are missing, which are physically on the Server. (all Agent reports all synced !).

Also: i can confirm the date "1. ‎Januar ‎1970, ‏‎01:00:00" - a lot of files lost their change- & creation date.

I really hope (i've got a lot of users), they didn't do the upgrade to 3.4 already.

I do expect an official communiqué from Nextcloud how severe the situation is and how / if the admin can/could downgrade.

And yes, i do really appreciate all the efforts from Nextcloud, but here i have to say .. did nobody test this before ?

[Githopp192]

just did the downgrade to version: 3.3.6

For the just discussed folder Recipes there is still the count mismatch of files & folders.

Recipes Folder on Windows 10: 1’476 Files, 305 Directories
Recipes Folder on Server: 1663 Files, 344 Directories

General status of the Agent: GREEN (= all sychronized).

(Folder Recipes has got "always keep on this Device" .. so my expectation is that i should have the same amount of files & folders in this case !? - or is my expectation wrong ? )

Environment background information:

• Support for Virtual Files is ACTIVE
• E2EE is ACTIVE (for that moment only one little folder is encrypted with E2EE (but not the recipes Folder !)).

When my expectation is true, then there might poppup the next question .. since how long this issue persists ?

[eibex]

All my files now show "Modified seconds ago" and "Invalid creation date" on Nextcloud, while on Windows they show:

[rrouviere]

find . -printf '%T@ %t %p\n' | sort -k 1 -n | cut -d' ' -f2- | grep ' 1970 ' | cut -d' ' -f7- | xargs -t -0 -d"\n" -i -- touch {}
Probably redundant but it worked for me (~2600 local, 3047 on the server side, some with various stuff in the filenames like quotes, weird characters, whitespaces...).

[godfuture]

For me this issue goes on with 3.4.2. The sync bar is doing stuff for hours. I thought I was safe from this issue and checked what could be the reason for such a long sync time...and yes, "he is back", slicing my data again:

Uninstall :)

[neufeind]

Had this issue with desktop-client 3.4.2 and a Nextcloud Server on 23.0.1. Downgrading the client to 3.3.5 worked. Also moving to 3.4.2 and upgrading the server tot the just released 23.0.2 seems to work as well. There were mtime-related fixes in 23.0.2, of which i assume they might have been related to the sync-client?

[stefan2904]

I just ended up in this issue because my nextcloud-desktop logfiles pointed me here ...

---

Since my client refused to sync with my server starting today, I was debugging what is wrong (and why it only started today).

In the client the error only says:

AccessDenied "Server replied "403 Forbidden" to "GET https://example.com/status.php\""

While in the logfiles (took me a while to find them and then to find this line) it also says:

"Nextcloud sync client v3.4.0 is blocked due to #4016. Please upgrade your Nextcloud sync client!"

While this makes sense, could you maybe add this information to a more visible place next time? Thanks!

[PhilippSchlesinger]

related:
#4319
nextcloud/server#31386

[dauni]

I have this behaviour with every single client version after 3.3.6. No matter if using server version 22 or 23.
The files in my group folder have correct dates, after synching with a Desktop Client newer than 3.3.6, some dates will become 1970-01-01 and the files aren't syncable anymore. The webclient displays as modification for these files time "now" - always "now"
So i installed 3.3.6 and the problems are gone

[Githopp192]

Dauni ... you have to upgrade windows client agent (i'm using now 3.4.3 and it seems to be stable).

The only proper way to solve this, is to do restore all the files with timestamp 1970 (golden rule: always have a backup !).

See the link to check all your files with wrong timestamps:

https://github.com/nextcloud/desktop/wiki/How-to-fix-the-error-invalid-or-negative-modification-date

[shibco]

I can reproduce this bug in Nextcloud Desktop 3.4.4. The documentation at https://github.com/nextcloud/desktop/wiki/How-to-fix-the-error-invalid-or-negative-modification-date should be updated to reflect this is not limited to a single version

[dauni]

Yes, it happens on every single version after 3.3.6.

• It happens with 3.4.0
• It happens with 3.4.1
• It happens with 3.4.2
• It happens with 3.4.3
• It happens with 3.4.4

The files have correct timestamps. After installing and using a Desktop Client newer than 3.6.6 some files will become timestamps in 1970-01-01 and i cannot sync them anymore. If i correct the timestamps, other files wil become 1970-01-01
Using desktop client 3.3.6 everything is fine

[Githopp192]

@dauni - what did you exactly try ? Did you try to make an update to 3.4.0 and then update to 3.4.1 and so on ?
As we know 3.4.0 had an issue .. so when you update to 3.4.0 you may run into this issue. Updating to 3.4.1 .. 3.4.2 will not fix this issue then on the same instance.

[shibco]

I am able to reproduce @dauni's issue across multiple platforms. Working with different users of my instance, this issue occurs both in cases where 3.4.0 is upgraded to a newer version number, and in cases where 3.4.4 is installed as new on a user's desktop.

[dauni]

@Githopp192 - now i got it. The old version seems to not care about the file dates, but the new versions do it. I had the problem also with new installations on new computers. After touching the files on the server it seems to work now.
Firstly i was confused, because after fixing some files, there appeared other files to be problematic, but at the moment the Nextcloud-icon remains green on all computers.

[Githopp192]

I am able to reproduce @dauni's issue across multiple platforms. Working with different users of my instance, this issue occurs both in cases where 3.4.0 is upgraded to a newer version number, and in cases where 3.4.4 is installed as new on a user's desktop.

@shibacomputer - as i wrote .. when you see this error with version 3.4.0 and then make the upgrade - you will still have got the issue. When you see this behave on a fresh install with 3.4.4 on a new client, then you would probably need to create a new case (from my perspective .. i did see some errors on 3.4.4 on GitHub - so i decided to run 3.4.3 - and as long 3.4.3 seems to run very stable).

That could be a general recommendation gents - before installing/upgrading a Nextcloud Agent (this may be true for every application) first have a pre-check to the Github Issues and check for current issues with this version, you want to upgrade.

[shibco]

As I've explained a few times now, this bug exists in both 3.4.0+ upgrades AND fresh installs of 3.4.4.

Also, given that the Nextcloud desktop client has an auto-updater, and I have an instance with non-technical users, are you seriously suggesting that I tell my users to come to Github to figure out whether the Nextcloud desktop app update is going to introduce bugs that destroy their data or its integrity?

[shibco]

This bug still exists in new builds, and now Nextcloud spams me with sync errors every 30 seconds. Actively hostile behaviour. Why even have an issue tracker if you're going to close bugs that clearly haven't been fixed?

[mgallien]

As I've explained a few times now, this bug exists in both 3.4.0+ upgrades AND fresh installs of 3.4.4.

Also, given that the Nextcloud desktop client has an auto-updater, and I have an instance with non-technical users, are you seriously suggesting that I tell my users to come to Github to figure out whether the Nextcloud desktop app update is going to introduce bugs that destroy their data or its integrity?

do you really think that we would ignore such a bug for 6 months without doing anything ?

[shibco]

Well given that this issue is closed and yet still persists, what am I supposed to conclude from that?

[platima]

Hey yeah I have given up on using the desktop client as it just repeatedly fails to sync ever 5 minutes and tries again. What's odd is that it does actually sync new files - I can see things I save on the PC in the cloud, and vice versa. I am getting a LOT of errors stating "Impossible to get modification time for file in conflict" though, and previously had the timestamp issue but resolved it.

[cknoll]

Today I shortly had a problem with this. The reason were some files and directories which had a strange timestamp. (1970-01-01 00:00:00). I solved the issue by applying touch (recursively) to all of them via the command line which changed the timestamp to the current time. For people coming across this issue who don't want to use touch: just re-saving the file should be enough. Directories might have to be temporarily renamed or recreated.

After fixing the date the desktop client worked like a charm again.

[platima]

Today I shortly had a problem with this. The reason were some files and directories which had a strange timestamp. (1970-01-01 00:00:00). I solved the issue by applying touch (recursively) to all of them via the command line which changed the timestamp to the current time. For people coming across this issue who don't want to use touch: just re-saving the file should be enough. Directories might have to be temporarily renamed or recreated.

Hey yeah this was a massive bug with the desktop client or something that shafted us all badly. I've got hundreds of files that'll never have the right date stamps again, but the instructions at https://github.com/nextcloud/desktop/wiki/How-to-fix-the-error-invalid-or-negative-modification-date fixed over 50% of them.