Irritating behaviour while repairing a library

Hi everyone,

I wanted to test the repairing of a damaged library.

Thus, I created a test library on a client which contained a file with some known content.
Then, on the server, I searched that content recursively in storage/blocks and simply deleted the file in which it was found. After that, I ran ./ --repair for the library.

And then, this happens on the client:

In seafile.log I see messages about receiving a 403 response code (see logs below).

So far, so good - apart from the misleading error message on the client, this is as expected from reading the manual.
But now I want to fix this by resyncing the library on the client and that doesn’t work, the client state doesn’t change.

The only thing that works then is to manualle unsync the library and then sync it again but that causes conflict files to be generated (even though it is a text-only file that hasn’t been changed in the meantime).

I stored more logs here in this Gist:

I wouldn’t want to tell a user to have to rename many SFConflict files by hand, so maybe there is another solution.



I’m not sure how currently is being decided whether there is a conflict or not.

It looks like no checksums are being involved, so it could be a good idea to compute a sha256 or sha512 (or even byte by byte comparison) in case Seafile thinks there would be a conflict and only create a conflict file in case the hashes differ.

Yes the re-sync operation doesn’t work in this special case. Re-sync reuses existing access token, which is removed on the server after a library is repaired from corruption. (That’s where the confusing “access denied” message comes.) The purpose of removing that is to force user to sync with their existing local folder again. In the process of repair, the corrupted file is set to empty content, so there will be conflict with your local file.

If we don’t force user to sync with local folder, there is a possibility of data lose. The local good copy could be replaced by the empty copy.

Looks like we have to update the manual to make it clear.

Hi Jonathan,

thanks for your clarification!
(I already suspected that it might have something to do with an access token.)

But could you think that it might be possible to prevent the creation of conflict files against empty files in such a specific case? I mean, the server knows about all the files that have been restored and so the client could get that information and replace the files with the good local copies without generating conflict files… Don’t you think?