File conflict problem

Seafile Client
1

Hi everybody, we have got a problem in seafile we don’t get solved (FYI: This problem has already been posted in the .de forum by other uers but without any solution or further hint what to do).
We use the seafile CE, server version 5.1.4. Concerned users use client versions up to 5.1.3 on windows 10 as well as on windows 8.1 (before updating to windows 10). We serve approximately 450 users in shared libraries.
The problem does not concern all users, but only certain users/installations: Conflict files are created by certain users when other users of the shared libraries work in files and save them. When synchronizing the files, these certain users/installations create conflict files by saving an old version of the same file - although these users definitively did not even touch the file (even for files they had never opened at all!).
In those cases, the seafile.log file says “cannot update” although the users do have full rights to read an write into the seafile library folders.
We already tested to save the mistakenly conflicted files into a different library, but the same effects reoccur in the same way.
We also tested what happens when windows indexing is deactivated for seafile libraries - without any effect.

I don’t know what to do any more - our users are dispairing. Any idea?

That’s what the seafile.log file says in such a case:

[08/01/16
16:53:48] [08/01/16 16:53:48] http-tx-mgr.c(4130): Download with HTTP sync
protocol version 1.

sync-mgr.c(660): Repo ‘***’
sync state transition from ‘initializing’ to ‘downloading’.

[08/01/16 16:53:48]
http-tx-mgr.c(1012): Transfer repo ‘b3d6fb85’: (‘normal’, ‘init’) -->
(‘normal’, ‘check’)

[08/01/16 16:53:48]
http-tx-mgr.c(1012): Transfer repo ‘b3d6fb85’: (‘normal’, ‘check’) -->
(‘normal’, ‘commit’)

[08/01/16 16:53:48]
http-tx-mgr.c(1012): Transfer repo ‘b3d6fb85’: (‘normal’, ‘commit’) -->
(‘normal’, ‘fs’)

[08/01/16 16:53:48]
http-tx-mgr.c(1012): Transfer repo ‘b3d6fb85’: (‘normal’, ‘fs’) -->
(‘normal’, ‘data’)

[08/01/16 16:53:48]
…/common/fs-mgr.c(301): Cannot update
C:/Users//Seafile*//.xlsx, creating conflict file
C:/Users//Seafile*//** (SFConflict *.**@.de
2016-08-01-16-53-48).xlsx.

[08/01/16 16:53:48]
http-tx-mgr.c(1012): Transfer repo ‘b3d6fb85’: (‘normal’, ‘data’) -->
(‘finished’, ‘finished’)

[08/01/16 16:53:48]
sync-mgr.c(660): Repo ‘***’ sync state transition from ‘downloading’ to
‘synchronized’.

1 Like
Seafile Server 5.1.11 Pro files not unlocking
2

Hi again, an important additional information:
As I wrote above, the seafile.log file of the conflicting client says “cannot update” and creates a conflict file based on the “old” version of the file - ALTHOUGH, at the same time, the client DOES update the file with the basic file name in parallel!
Maybe an issue concerning the client?

3

No ideas? I would really like to continue using seafile with our users and win back a positive user experience… Thanks for your help!

4

Thanks for the information. Currently we can’t reproduce the problem.

We are busy with other tasks. We will come back to this problem later.

5

This is because if Seafile client failed to write to the file. It will rename the local file to a conflict file and then write the new version to the old path.

Does it only occur to xlsx files?

6

No, it also concerns xls, doc and docx files.

7

As said before, the problem is caused by Seafile client failed to write to the file directly. But somehow, the client is able to rename the file to conflict file and write the new version to the old path.

Can you try download the a version from the server and overwrite the old file with a new one via copy/paste?

8

I just tried that and it works in the usual way: When I paste the downloaded file, Windows Explorer aks me if I want to replace the file - after confirming this, it just overwrites the file.

9

I will discuss within our team how to debug the issue and come back later. (Some of our developers are in vocation this and the next week.)

10

thank you very much so far for picking up the issue!

11

Do you see the following message before this message?
“File xxx is updated by user. Will checkout to conflict file later.”

12

no, I can’t find a message like that.

13

Then it’s possible that the file is somehow locked (opened) by other application. Could you check this situation with windows process explorer tool? There is a tutorial here: http://www.techsupportalert.com/content/how-find-out-which-windows-process-using-file.htm

You just need to reproduce the conflict situation and when it happens, check which process is opening the file.

14

Thank you for this hint. Unfortunately, we were not able to identify processes which opened the file (as the file is not opened). To be honest, we are not sure if we handled the tool in the right way.

But we found out another interesting information by testing: We had the possibility to look in detail at some of the users who cause conflicts, and they all use ESET NOD32 as antivirus program. After disabling this program, we didn’t get any more conflicts.

As we don’t want to disable the antivirus program on the long term, we tried out to enable it again and to find out a detail configuration which works. We disabled just the “file creation” scan function - at the moment, this seems to work (ESET NOD32 version 9). But of course, this can only be a very temporarily solution.

Maybe an incompatiblity of the seafile client and ESET NOD32?

15

Perhaps that’s because ESET locks the file when Seafile client tried to rename to it? Could you check which one of the two files after conflict is the version from the server? The file with original name or the conflict file?

16

In the end, the version from the server (=the “good”, new version) gets the one that has the original name; the “old” local version gets the new version named …SFConflict (which, of course, will also be communicated by the server to all clients with the changed name). In those cases, user can generally delete the conflict version - but of course, they are irritated by the number of conflict files.

17

I can verify these problem with ESET (Version 9).

Deactivating the real time fileprotection for new build files (extendet adjustment - real time protection) solving seafile conflicts problem during runtime.

This can be only a temporarily solution cause i dont want to deactivate components of my antivirus software.

THX for your support!

18

Of course, but this work around helps us to understand what happens. We are not going to roll out this to dozens of users, either. It was only supposed to be a work around, not a solution. Thank you for testing!

19

Thank you for testing this. We’ll install ESET and find out how to improve the file updating routine.

20

Fine, thank you very much!

By the way: on one of our computers I found an installation with ESET - but with an old version 7 (7.0.317.4) which had not been updated to version 9. Those file conflict problems did not appear with this old version. So something must have changed between ESET versions 7 and 9 which causes this different interpretation in the seafile client.

Have a nice weekend!