Skip to content
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

"Couldn't update placeholder info" Version 3.9.1stable-Win64 (build 20230725) #5955

Closed
HEtchevers opened this issue Aug 4, 2023 · 6 comments

Comments

@HEtchevers
Copy link

This issue STILL exists with a slightly different error message in version 3.9.1: Couldn't update placeholder info. It has happened for (nearly) all of my nearly 6000 files and they all try to synchronize constantly and fruitlessly. They seem to be present on the server though.

image

--

Follow-up: in the "activity" bar online, it lists that I have either "changed" or "created" the individual files. I have been able to upload and sync some new files since, though, since this problem appeared a few days ago.

In refusing the client update on my office desktop so far, I do not have any of these error messages and all appears to be normally sync'd with what is already on the server or new files I create.

However, from my laptop, new data is not correctly uploaded and sync'd to the server.

Originally posted by @HEtchevers in #4401 (comment)

@HEtchevers HEtchevers changed the title "Couldn't update placeholder info" "Couldn't update placeholder info" Version 3.9.1stable-Win64 (build 20230725) Aug 6, 2023
@allexzander
Copy link
Contributor

@HEtchevers

What happens if you pause the sync of the current folder (in the Settings dialog context menu), and then add only that specific folder from the screenshot as the remote root as the second sync folder and uncheck "Use virtual files"? Do you have all those files synced, or are there errors displayed in that scenario too? Asking this for the sake of checking if the issue is with VFS or with how files are handled in case of general error.

@dancrick
Copy link

I see the same warning messages (Couldn't update placeholder info), but only for files recently created. Any updates please? I am on version 3.9.2 (windows-10.0.19044). Thanks.

@HEtchevers
Copy link
Author

@HEtchevers

What happens if you pause the sync of the current folder (in the Settings dialog context menu), and then add only that specific folder from the screenshot as the remote root as the second sync folder and uncheck "Use virtual files"? Do you have all those files synced, or are there errors displayed in that scenario too? Asking this for the sake of checking if the issue is with VFS or with how files are handled in case of general error.

Apologies for not getting back to this quickly. I ended up simply removing Nextcloud from the problematic computer (which changes my workflow) waiting for another version. However, given @dancrick 's posting, I will go back and try with 3.9.2. When I paused the sync before as requested, @allexzander , I did have the same error even without the use of virtual files. I'll try again tonight when I can. Meanwhile, on my office computer, I'm sticking with a functioning 3.9.0 for now.

@Wonderkitten
Copy link

Same issue on 3.9.2 windows-10.0.19045 - but was localised to files within a certain folder.

It was resolved by manually creating another folder and moving the files across (all within the web interface). Desktop client is now syncing everything happily.

@dancrick
Copy link

Thanks. Fixed for me by making new copies of the files that were triggering warnings, and deleting the old ones (using syncronised virtual files, not in the web interface).

@HEtchevers
Copy link
Author

Also thanks! My (known) offending folder is 20Gb, shared with me by a colleague. A few of the subfolders or lone files in the tree had been labeled as constantly syncing from my working client 3.9.0. When I looked inside, some of those subfolders were empty. Making new copies of specific files with eternal sync and deleting those original synced virtual files helped. Everything seemed to sync to a green check or cloud (kept on server) as expected.

I then installed 3.9.2 windows-10.0.19045 using the virtual file extension wincfapi. It all appeared to be fine, with a green check in the system tray and same after re-launching sync. Recent activity from today appeared both in tray and on web interface list.

The trigger for this error appears to be changing properties in Parameters to (right-click) Availability > Always keep a local copy. Doing this for the 20 Gb folder shared with me (I should have started smaller) immediately leads to these errors for every file therein.

Changing back to "keep on server" takes much longer and entails enough read-write to disk activity that it appears those 20Gb are being entirely transfered back rather than simply any updated files. As soon as a new sync starts, the attempted (and unsuccessful) transfer restarts. I suspended sync.

If it is possible to break everything by toggling this option then it should be harder to make that choice or the implications made clearer. When I started having problems with internet connectivity, I wanted to keep copies of my most important files locally.

Having done so in early August had created a strange file in the most commonly used subfolder I'd wanted to have a local copy of, called "37a13952". Looking at it in Notepad++, it's machine-readable with a few recognizable file paths from the culprit folder.

For others like myself who don't understand, here's an explanation of the concept of virtual files in Windows on Nextcloud. (I still don't really understand.)

I did move an urgent subfolder out and that successfully syncs so the files are not corrupted, just the original path in some sense. I'm trying to disconnect entirely from that shared folder, having backed up a copy of the files on my local hard drive, but it will take time.

Thanks to other users in the thread for their validation, help and ideas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants