Duplicate folders and SFConflict files

Hello,

We are running a hosted version of Seafile (server version 6.1.9) and one of our customers has some duplicate folders and many SFConflict files. This customer is running Seafile Client 6.1.1. on both Windows 7 and 10 machines.

This is only happening in one repo (checked successfully with seaf-fsck) and on two folders.
The issue is not related to a display problem, because we can see the duplicates either online and in the local file system.

Any idea of how I could solve that (and what is happening of course) ?

Thanks in advance !

Can you post some more info? Files which are doing conflicts, logs and etc.

Thanks for your fast answer.
What kind of log do you need to get ?
I will post them with the file and folder names.

It can happen when both users edit the same files at the same time.

Hello,

The directories that are duplicates are called for instance “STAGES” and “Stages”.
Regarding the SFConflict files, here is a screenshot demonstrating the problem…


And finally, which log wold you like, and where should I post them ?
I am not very keen on the idea of publishing the logs (with servers, users, libraries and file names) onto a public forum :slight_smile:

Are usernames in conflict files same or different?

The user names are differents.
In fact, in the example shown, we have one original file (stats CJ 2017.xls) and many conflicts from 5 different users.
In the conflict list, you can see SFConflict files which have been modified by two different users within 1 second of difference. In this case, everyone can understand that we can have a conflict. However in the other cases, the file timestamps are very different.

Within the duplicate folders, we have the exact same files, with the exact same conflict timestamps. Which, in my point of view, really is a problem linked to case handling in the folder names.

For Windows these folders are the same.

You are right. Even though NTFS is case sensitive, Windows does not support file names that only differ by case sensitivity… I should have thought about it :confused:

We will try to move the data to a new directory to see if it solves our customer’s problems.

I’ll keep you informed !

1 Like

No news from our customer… It probably means that the problem is solved.
At least, I hope so :slight_smile:

Thanks for you answer

We are experiencing a similar issue. We are editing an office-file in a synced library while at the same time the folder in which the file resides is being renamed to a name that only differs in upper/lower case of at least one letter (i.e. Test -> test) the seafile client reports a problem about the file being opened. So far so good. When I close the office-file the client it sometimes (!) starts to sync the library correctly. But in other cases we experienced the client not being able to resolve the error. When manually resynched, the library contains two folders (Test and test) of which only one is synched to each of the clients. This leads to funny errors and more and more conflict files.

It appears that the client propagates local changes correctly, but changes/commits coming from another client get merged into the folder that already exists locally.