Garbage collector marks libraries as corrupt but fsck doesn't detect any errors

seafile@mercury-sv:~$ ~/mycloud/seafile-server-latest/

Starting seafserv-gc, please wait ...


[07/01/18 02:14:50] gc-core.c(384): === Repos deleted by users ===
[07/01/18 02:14:51] gc-core.c(456): === GC is finished ===
[07/01/18 02:14:51] gc-core.c(460): The following repos are damaged. You can run seaf-fsck to fix them.
[07/01/18 02:14:51] gc-core.c(463): 5ed94422-5b01-4ab0-8c51-f80743dc6be5
[07/01/18 02:14:51] gc-core.c(463): 72a3dda3-95b3-440b-b2b3-e816c6e10be9
seafserv-gc run done

seafile@mercury-sv:~$ ~/mycloud/seafile-server-latest/ --repair 5ed94422-5b01-4ab0-8c51-f80743dc6be5 72a3dda3-95b3-440b-b2b3-e816c6e10be9

Starting seaf-fsck, please wait ...

[07/01/18 12:34:37] fsck.c(586): Running fsck for repo 5ed94422-5b01-4ab0-8c51-f80743dc6be5.
[07/01/18 12:34:37] fsck.c(413): Checking file system integrity of repo Gaming(5ed94422)...
[07/01/18 12:34:55] fsck.c(650): Fsck finished for repo 5ed94422.

[07/01/18 12:34:55] fsck.c(586): Running fsck for repo 72a3dda3-95b3-440b-b2b3-e816c6e10be9.
[07/01/18 12:34:55] fsck.c(413): Checking file system integrity of repo Gaming Bulk(72a3dda3)...
[07/01/18 13:01:31] fsck.c(650): Fsck finished for repo 72a3dda3.

seaf-fsck run done


As you can see, libraries 5ed94422 and 72a3dda3 are marked as corrupt when the garbage collector tries to scan them, but fsck doesn’t try to repair them. What’s wrong with them?

Did you try to run fsck over all libaries?

I think this is important:
6.3.1 (2018/06/24)
Allow fullscreen presentation when view ppt(x) file via CollaboraOffice.
Support mobile UI style when view file via OnlyOffice.
Some UI improvement.
Show terms and condition link if terms and condition is enabled
[fix] Update OnlyOffice callback func (save file when status is 6).
[fix] Show library’s first commit’s desc on library history page.
[fix] Check if is an deleted library when admin restore a deleted library.
[fix] Removed dead ‘quota doc’ link on user info popup.
[fix] Fix bug of OnlyOffice file co-authoring.
[API] Add starred field to file detail api.
Use ID instead of email on sysadmin user page.
[fix] Fix database upgrade problems
[fix] Fix support for sqlite3
[fix] Fix crash when seaf-fsck, seaf-gc receive wrong arguments

Fsck only scans the latest state of the library while the garbage collector also looks at the history. Thus history corruption won’t be detected by fsck.

I assume then that commits to libraries in a corrupted state are allowed. Any workarounds?

Only creating a new library and uploading the data again.

On commit corruption won’t be detected and corruption in the history doesn’t matter until one tries to access affected data via history. It most likely (didn’t look into the code but would expect that in theory a commit - which also is a file - could get lost and would hide everything committed before from the history) works. Affected files will be empty.