I have Seafile client running on Windows 10. I noticed yesterday that one of the local folders was saying “12 days ago”, and had the cloud symbol instead of the tick. So somehow the connection between that local folder and the cloud had been lost (perhaps because of a repair installation of Windows 10). How do I reinstate the connection so that the folder starts syncing to the cloud again? What I want to avoid at all costs is the out-of-date cloud version overwriting the local copy. I have made a lot of changes to files in the folder in the last 12 days and I want those replicated to the cloud.
Make right-click on library in main client window and on the bottom hit “Resync this library”.
When I did that yesterday, I had to select a folder to sync it with, as it had lost connection with the local folder. I selected the one that the cloud version is a copy of, and it then proceeded to download the entire cloud copy into a new folder within the chosen one. That is, I selected my “C:\shared\projects” folder and after the sync ended up with “C:\shared\projects\projects”. I’ve now deleted that folder and want to re-establish the link with the cloud folder. When I hover over the cloud icon, it tells me ‘This library has not been downloaded’. Right-clicking on it gives me the options ‘Sync this library’, ‘View on cloud’, ‘Open cloud file browser’ and ‘Show details’. I DO NOT WANT to download this library. I want to make sure that my local ‘projects’ folder is backing up again to this cloud library. What do I do?
Can you please provide screenshot of your client’s main window? And list which libraries should be synced?
I simply want to sync my C:\shared\projects folder with the ‘projects’ library shown. What is on the cloud is a copy of my C:\shared\projects folder. I want to continue using it, so I don’t have to start from scratch and upload a few gigabytes of data unnecessarily.
OK, now it’s clear for me.
You don’t have synced Projects library. So click right on it and select “Sync this library”. In dialog which open after click look for link with caption “sync with an existing folder”. Dialog window will refresh little bit after click on this link. But Input caption will change to “Sync with this existing folder”.Then just select your “C:\shared\projects” and seafile will automatically merge your changes with existing files on cloud. I made some screenshots for you
Standard sync dialog:
This is what you want:
Thanks. I think this is what I did yesterday, resulting in the extraneous nested ‘projects’ folder, but I’ve given it a go again. It took a long, long time with ‘Downloading file list’, and now it’s showing ‘Downloading files…0%’ and has been for some time. I’m slightly anxious about it overrwriting all my local versions (as opposed to the other way round, which is what I want). I just don’t see why it should be downloading files at all at this point, as opposed to uploading them. I’ll report back if it gets beyond the 0%.
OK, it’s still not moving on and I can see why not, because the seafile.log is full of messages like this:
File C:/Shared/projects/barnes/barnes1/.idea/workspace.xml is updated by user. Will checkout to conflict file later.
I assume that it means that in its eyes there’s a conflict - the local copy has been updated. But I know that! I just want the changes to the local copy to be reflected in the cloud copy, just as it was before the glitch 12 days ago. I don’t see why this is proving so difficult.
1 Like
There is no option to fix it. You have to delete the Files somewhere or you will get duplicates like example[filesync error].jpg
It is as I feared, or rather, worse. I don’t have the nested ‘projects’ folder now. But what I do have is all my changed files being replaced by old versions from the cloud, the changed local copy being renamed e.g. ‘Config (SFConflict xxx@xxx.com 2018-03-23-13-14-41).groovy’. This is pretty disastrous, so I’ve aborted the download half way through. I will now have to choose whether to go through and rename all the SFConflict files again, or to revert to a backup I took last night (I’ll probably go for the latter).
This is crazy. It is a pretty stupid design decision. I’ve been relying on Seafile for a while now but this seriously worries me and makes me think I should look elsewhere. The fact that I cannot easily and reliably re-establish a sync between a local folder and the cloud copy is a serious deficiency.
It could be a corrupt library. You might try seaf-fsck on the repository and see if it reports anything. If not, then I would make a copy of the folder on the client PC. Then, unsync the library, and then set the sync back up again. If it does overwrite the files with an older version, which is unlikely, then you can simply copy the files from the copy you created and overwrite them. It should then sync the correct versions back to Seafile.
Thanks for the suggestion. Not sure how to go about doing seat-fsck on the repository, as I’m using a hosted service, but there may be a way.
I’ll check and see.
As long as you can view the repositories, and you should be able to on a hosted plan, here is the syntax to check for corruption:
Checking Integrity of Libraries
Running seaf-fsck.sh without any arguments will run a read-only integrity check for all libraries.
cd seafile-server-latest
./seaf-fsck.sh
If you want to check integrity for specific libraries, just append the library id’s as arguments:
cd seafile-server-latest
./seaf-fsck.sh [library-id1] [library-id2]
If fsck does indicate that you have a corrupt library, the syntax to repair is:
cd seafile-server-latest
./seaf-fsck.sh --repair [library-id1] [library-id2]
I had to give up in the end and start from scratch with this library. I renamed the library ‘projects-old’, created a new sync and once that was completed (5GB uploaded), I deleted the old one.
That’s usually the easiest and quickest way rather than tinkering with trying to fix one. Any time I have corruption, I usually just make a backup of the files on one of my synced computers, then I unsync the folder on that client, then delete the library in Seafile, then recreate the library by dragging and dropping the folder on the client into the client app in order to start a new library.
Just had the same problem again, where a folder hadn’t sync’ed for 22 hours, and exiting and restarting the Seafile client didn’t kick start it (as it sometimes can). I managed to get it going again by killing ccnet.exe in Task Manager and then starting the Seafile client.
Putting this here in case anyone runs into this problem.