-
Notifications
You must be signed in to change notification settings - Fork 807
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Cannot sync due to invalid modification time" #4378
Comments
Identical problem with Windows 11. Client version is current 3.4.4 Trying to fix the problem by setting the date of the last modification via Linux command touch to the current date does not interest the client. Even after a clean reinstallation of the client, the sync errors reappear right after the first sync. Is there a possibility that the sync errors are stored in the database, preventing the client from starting a proper sync? edit
If the sync continues to generate errors, you will need to manually clean up the user's deleted files on the server. |
Thanks, this method works and I have fixed it. |
nextcloud-client: 3.4.4 Saw this error today on my main
gives no results. Are there any instructions/steps what else could be done/how to solve this issue? Inside [Edit] On the server drive (ZFS), the folder has the correct date:
Atm. I assume this happened because I deleted a single photo through the web app today. I usually never do this (always remove the files on harddisk and let it sync). However, I don't know why this resulted in a broken timestamp on Nextcloud's database, and I don't know why it cannot get the correct one from the filesystem, since it is all there and correct. [Edit2] Also tested solvable_files.sh with [Edit3] No way to solve this error with the Leaving this at it today, perhaps tomorrow someone will find a solution. Here're the log lines from Desktop Client that appear to point to the issue: click
|
Solved it for the moment: choco uninstall nextcloud-client
choco install nextcloud-client --allow-downgrade --version 3.4.3 Now the desktop client syncs again and does not error on Modification date. The wrong (future) modification date on |
Hi. That’s how I managed to solve this First of all you need to find all the files with destroyed timestamp find yournextcloudfilelocation/ ! -newermt 1970-01-02 > damaged.txt #!/bin/bash file="damaged.tx" while read -r line; do Then If you use docker sudo docker exec --user www-data your containerID php occ files:scan --all sudo -u www-data php occ files:scan --all after that you need to sync all your clients from scratch |
@andyxheli Thanks andy. I tested these steps. There was only one folder affected: My main Here is how I solved this (just now).
What wasn't clear to me is that Also updated |
Also if you have a Windows client, you can fix broken files from the client-side with this PowerShell one-liner (run it in the NextCloud folder in your user profile):
|
I doubt this would work, since the client refused to sync to the server (at all) - because the wrong date was on the server (database only, fs not affected), not on the client side. |
Works for me, mate 🤷♂️ - all green and happy now |
Thanks, that worked for me to adjust the filedates, just had to change the timestamp to [datetime]::new(621356004000000000) as mine were 01.01.1970 01:00 instead of 00:00. |
Didn't work for me, it looks like the problem lies in the cloud database on my end too |
Apparently the 01.01.1970 is not the only problematic date, with the update to version 3.4.4 on Linux Mint 20.3 some files suddenly got the modified at 07.02.2106. Fixing on the client side works with |
We also had some cases of "Cannot sync due to invalid modification time", but instead of the other solutions, which work on the client-side, we solved this on the server-side, which might be a good idea in case you've no access to some clients yourself. SolutionI found some entries in the data base table In a second step I replaced the SELECT *
FROM oc_filecache
WHERE oc_filecache.mtime <> oc_filecache.storage_mtime
AND oc_filecache.mtime NOT BETWEEN 1000000000 AND UNIX_TIMESTAMP()
LIMIT 100
; |
Can confirm this fixed the issue on my end |
I wanted to try this out but I'm not an SQL expert. I was able to get into my PSQL database, connect to the database with oc_filecache table, however, running the command caused issues.
Is this SQL statement for mysql instead? If so, can someone help me undertand the error message and/or tweak it for PSQL? |
I ended up using:
However, it didn't work for me because BOTH mtime and storage_mtime for those entries were 0. I ended up getting the current unix timstamp manually, and then replacing the text "1234567890" with it.
|
This resolved my issue: I checked all files and dir up to 1980 THAN
From 2023 up to 2200 as I had files modified in futur (86 years from now) You should not have any error Now fixed !!! Those files were on a Mac going to Windows by USB key and sync some years ago to my nexcloud server (Linux Nexcloud) Hope this help ! C. |
@jreed1701, I just remember problems with the desktop client version 3.4.0, that might be related to your problem and that's further explained othere here: https://github.com/nextcloud/desktop/wiki/How-to-fix-the-error-invalid-or-negative-modification-date |
Thanks @lars-sh - I followed the procedure and running ./solvable_files.sh just returns and does nothing. I'm sure I have the right arguments because ./unsolvable_files.sh works just fine. |
Resolved with this command, but expanded date to 1969-12-31. |
I got fed up, wiped my nextcloud server to start over. I ended up using the 3.3.6 client on Windows and that worked fine. I don't plan to upgrade until there's some definitive fix in the next release. Hopefully the admins communicate that clearly. |
in my case i think this occurred when I changed the folders being synced in the client while a sync was trying to pull down a bunch of files. After checking an additional folder and pressing apply, I started receiving these errors and the mtime in the database doesn't seem correct any longer. |
This bug burnt me severely in 2021 as mentioned in the OP, and its amazing to see this regression emerge again, first on Windows and now on Linux (Fedora 35). I literally have no real way of handling this with my users except to blanket ban the desktop clients, which is wild. |
I see this even though there are no actual invalid modification times, neither on the server nor on the client. |
I have the same problem. No invalid modification time on the files. Seems I just moved some files to a different folder on the client at the wrong time (during upload?). EDIT: Turns out, the did have the invalid 01.01.1970 modification time. Just not on the server itself, but only on the client. So the have been uploaded but syncing to other clients did not work. |
I'm having the same problem on desktop client running on Win10. MacOS and mobile clients are running without issues. Tried to fix the mtimes with server side commands suggested above and also do So I started reverting back old client versions one by one and the the first version to fix that problem was version Nextcloud team please address this bug with more serious attention. It's obvious that a change between I'm ready to assist and provide log data if needed. Just let me know. |
I've now started hitting this again too. I'm getting all the errors on my Nextcloud Android client which keeps asking me to choose which file to keep (local or server) for 49 files that have mysteriously now got the wrong date (1970 as so many others in this thread). Although whilst I was at first able to choose which one I wanted to keep (I went for the server ones which still had the correct date), now if I click on any of the notifications I just get an error |
i just set up nextcloud on a new linux machine (v3.10.1 from snap) and got this again. only some files are affected. |
Okay this is now with 212 upvotes by far (next is 66) the most upvoted issue on nextcloud/desktop. I've no idea when those votes appeared (i.e. whether there was a recent development in this bug hitting more people) but at any rate it would be appreciated by a ton of people (assuming that not everyone hit by this actually comes here and has an account to upvote) if someone from the dev team could acknowledge this bug and give some feedback. I know this is open source, but Nextcloud is also a bigger piece of software which is not that easy to work on without prior knowledge (at least that is what I think) so if you need funding to work on this DO let us know. |
I believe it had like 100 upvotes on the first 3 days of posting it. It's a long-running issue that's still not resolved, even worse, it directly corrupts your files. Also, I don't think they are ignoring it, a few weeks back there was an update: @jancborchardt jancborchardt moved this to from 🧭 Planning evaluation / ideas to 🏗️ At engineering in 🖍 Design team on Aug 31 But yeah, some official response, in a form of a comment at least, would be nice. |
I had a similar issue and inspired by this comment I figured out I had some entries in the nextcloud database where The same files on the server had a mtime of Unich epoch (1970-01-01) while the files on the client side had a timestamp sometime in the future (2106-02-07, not something recognizable to me at least). I ended up deleting the entries with the bogus mtime from the database:
found the files one the server with an mtime of Unix epoch:
and gave them a more reasonable timestamp. Deleted the affected files from the client and ran:
on the server. The files end up being synced and I haven't seen the problem. The above steps are more or less from memory as I cannot recall exactly what I did in which order. Some steps might not be needed and you might end up losing data by trying this. Just sharing this in case someone might find it helpful and in case it might help getting to the root cause of this issue. |
Been there, done that. Didn't help. Tried on multiple machines. |
This issue has returned for my instance just in time for 2024 🥳 |
Similar to the comments above with the Powershell script, I was hitting this issue when trying to sync a bunch of files to Nextcloud for the first time. Some of those files didn't have a good Last Modified date, so I needed to fix that. I found that changing
Add Full command: My files did successfully sync to Nextcloud after this. I suppose a past version of the client didn't mind these messed up dates, and would successfully sync them to Nextcloud. And then Nextcloud changed to not accept the messed up dates but people already had some on the server, which is what seems to be afflicting 90% of the people in this comment section. |
This happens to me on Mac. Works great on Ubuntu client. Then every once in a while I need to sync the files to a Macbook. The Mac is running the latest client version. I get a sync error and the file timestamp is 422 years in the future. |
The bug seems to be present for almost 2 years - Can we get a developer response? |
Nah. Who cares about 240 confirmed cases of file corruption? |
My files' modified timestamp is set to when it was initially created, which predates 1970 in over 10,000 cases. Before officially supporting it, it would be nice to be able to ignore these errors. However, supporting them would be more ideal. |
That would be nice. Unbeliebable that 2 years later there is no fix for this rather than "playing" with the database and with the data directory without warranties.... |
For Windows, if you need to find the exact timestamp to look for (#4378 (comment)), you can get it by running:
Then replace the above command. |
I did some Julia scripting to update the problematic modification times. I used the Initially, I called invalid_date_dir = "directory/contining/your/problematic/files/and_or/folders"
problematic_mtime = -3600
for (root, dirs, files) in walkdir(invalid_date_dir)
for dir in dirs
if mtime(joinpath(root, dir)) == problematic_mtime
try
cmd = `touch $(joinpath(root, dir))`
run(cmd)
@info "Updated modification time of directory $dir"
catch e
@warn "Encountered error while touching directory $dir. Continuing"
end
end
end
for file in files
if mtime(joinpath(root, file)) == problematic_mtime
try
cmd = `touch $(joinpath(root, file))`
run(cmd)
@info "Updated modification time of file $file"
catch e
@warn "Encountered error while touching file $file. Continuing"
end
end
end
end I realize that this is done by others previously in this thread, but not in a way I could read and understand. I feel like this is rather clear, if you happen to have Julia installed. |
I downloaded a folder from Google Drive, unzipped it, and copied it into the NextCloud sync folder. Almost all the files had this error! I did not need to preserve the modification time of the files, so I just killed them all with However, for a non-technical user, this is a showstopper bug. (Also, I had a file with a very long name. The sync client got stuck in a loop inundating the desktop with the notification that the file has invalid characters...) |
https://drive.google.com/file/d/1BxhpYyyVDNbsGdlh7DjhVnK4doswGAEQ/view?usp=sharing |
How to use GitHub
Expected behaviour
It should be able to sync files with no issues
Actual behaviour
Complains about invalid modification time while basically everything else works perfectly with the same files
Steps to reproduce
Client configuration
Version 3.4.4 (Windows).
Operating system: Windows 10
OS language: US ENG
Qt version used by client package (Linux only, see also Settings dialog):
Client package (From Nextcloud or distro) (Linux only):
Installation path of client:
default
Server version
22.2.5
I can see that it had ruined many people's files back in 2021 https://syncloud.discourse.group/t/disaster-with-nexcloud-3-4-0-client/141/4
But I am not sure if I was using the same instance back then. It seems this issue is still present. I am spending hours on trying to move files, rescan them, whatever. It is really making me stop recommending this (potentially) amazing product to anyone.
The text was updated successfully, but these errors were encountered: