Corruption when two machines making changes to library at same time

[Larrikinau]

I use your customised setup for seafile. Thank you very much for all the effort you've put into it. Since moving to this setup, I find that the performance of syncing is slower - presumably because of all the different dockers that now exist and connect via networking (guessing as that is the reason). As a result, if two people are sharing the same library, and changes are made at the same time, given that the sync is slow, (using the seafile sync client 8.08), that the library immediately becomes corrupted.

This didn't happen under the standard docker config that is supplied as I found that the syncing was faster, resulting in less likelihood that two machines would literally try to sync at the same time (despite two users sharing the same library making changes at the same time - seafile would instantly update itself).

Is this a common problem with this particular setup? It's almost becoming unusable for me to continue to use as my shared libraries are constantly getting corrupted when it's being used simultaneously by more than one user.

Any advice / help would be greatly appreciated.

[Larrikinau]

@ggogel Any thoughts on this? Thanks!

[ggogel]

Hi, I've created this projected almost two years ago and you're the first person, who reports this kind of issue. I personally use it with at least five clients and it's working just fine for me.

The only time I ever had a corrupted library was when I was using the new golang file server. Which fileserver did you have configured?

And by the way, not "all the different dockers" communicate with each other. Only seahub and seafile-server communicate with each other via TCP instead directly over a unix socket. TCP guarantees that all packages arrive and are in the correct order. So this network communication can't cause any corruption. Can it be a little bit slower? Maybe. Although I didn't compare it with benchmarks, I personally didn't feel any difference in performance.

[Larrikinau]

Thanks for taking a look into this. I appreciate it.

I am using the new golong server. ie I have:

[fileserver]
use_go_fileserver = true

in my seafile.conf

Seafile server version is 9.0.9.

Regarding TCP comms, fair enough. Understood. I honestly don't know what to do. Just try and avoid modifying the same library at the same time I guess...

I am staying with your recommended setup and I use traefik as my reverse proxy.

[ggogel]

You're welcome :)

Try to disable the golang fileserver and see if the issue occurs again. From my experience, the golang fileserver isn't production ready yet.

[Larrikinau]

Sure. I've just changed this to:

[fileserver]
use_go_fileserver = false

I presume that will do the trick? I understand I can comment it out as well as it defaults to not being enabled, but for completeness, I thought I'd leave the line in there with false in case one day it can serve as a reminder to change it if required.

[Larrikinau]

@ggogel Many thanks for your help. I have fixed the issue. It was a combination of two things:

1. Disabling the golang fileserver with the above use_go_fileserver = false
2. Traefik was running 2.6.2 which I have subsequently upgraded to 2.9

Thank you again for both your support and also your excellent dockerisation of seafile. I think you have made it the best practice on implementing seafile in docker. I hope you continue maintaining it :) A big thank you from me.