Seafile Client 6.1.0 EML files and antivirus


#1

I thought this will be a easy friday, i was wrong.

I synct a new client (6.1.0) with 5 libraries. After an hour he was still downloading … i checked and got a ton of SFConflict files.

From ALL users who are in sync with this 5 librarys and have version <6.1.0. Our Library locked like this:

This is just one Folder. It was everywhere. But only EML files. (Side note: Seafile does NOT check if the path is getting to long with his SFConlict files, which makes a pain in the butt to remove them all).

What i think happened here is our AntiVirus is in conflict with Seafile. But this didn’t happen with older Seafile versions. Is there any magor diverence betwin 5.1.4 and 6.1.0 wich could this make happen?

The Library works as long as i only have one 6.1.0 synced with a library. As soon as i add a second client with this version the chaos beginns.

The strange thing is, the conflict files only comes from Clients older than 6.1.0 but only happens if two 6.1.0 clients are online.

I now have almost every client Disconnected. And reset the Library.


#2

UPDATE

it seems that one 6.1.0 witch makes a fresh sync is enough to make this mess

UPDATE2:

i removed now ANY 6.1.0 Client and Seafile works again. Luckily an downgrade to 6.0.7 is easy.


#3

We have the same problem: .eml files cause thousands of conflicts (although not in use at all), never ending…

We have several hundreds of users and don’t have a realistic possibility to downgrade all clients to 6.0.7.

Would it be possible to publish a new release without this bug so that we can just inform all users to upgrade to the new version? As the update function works automatically, this ist much more realistic than a downgrade…

Thanks for your help!


#4

We will check the problem.


#5

@scheibenleger what antivirus Software are you using? We have Eset endpoint protection. Maybe it has something to do with that.


#6

Most of our installations use ESET, too!


#7

@scheibenleger maybe you can add an exception for EML Files in the ESET Administrator as long there is no other Solution to this. Not the best solution but better than thousands of conflict files.

It is not the first time i had an incompatibility. I had Acronis Backup installed, as soon as Seafile and the Acronis Backup Service is running (wich is always) the Explorer.exe runs at full load on one thread. It took me a while to resolve this.


#8

Hi Andre,
we already had an incompatibility between seafile and ESET last year which caused conflict files, too. To resolve that, the seafile client was modified and it worked normally again for several month!
This time, we also thought about adding an exception in ESET, but we did’nt do that for two reasons: First, this would be a loss of security - second, we have more than 500 users and we would have to configure that on all PCs manually (a server based solution is in work but not productive yet). The work around we try now is to rename all “.eml” file endings to “.em_” - at the moments, there are no new conflicts. I hope it continues to work in order to stop the never ending conflicts… (3x auf Holz klopfen!)


#9

Interesting to hear, we now had two separate customers who were using Kaspersky (and another one i don’t remember) and had problems with conflict files too.


#10

Were you able to reproduce the problem?


You do not have permission to access this library
#11

@Andre @scheibenleger

We haven’t had time to reproduce the problem. But after some analysis, I think this issue is related to the change of file block size in 6.1 version. Usually the behavior is compatible. But in your cases, the eml files last modification time just get changed without changing the contents. Mixing with the change of block size, it creates conflict files.

One solution is to upgrade all clients to 6.1.x so that all clients use the new block size to index new files.

UPDATE:
We’ll also improve the conflict detection algorithm to include checking of file size change. This should further avoid the creation of false conflict files in many cases.


#12

Version 6.1.1 is available to download. Seafile will ignore timestamp change of EML files. It should be able to fix the problem.


#13

i think, i have another eml related problem.
i can’t delete them. It is a pain to get them really removed.

if i remove an folder with eml files in it, another user recreates it. Only EML files. Nothing else. But only on boot/reboot of Windows or the Seafile Client.

In Seafile.log i have tons of this:

[04/06/18 09:07:26] vc-utils.c(934): File C:/Users/path/xyz.eml is changed. Skip removing the file.
[04/06/18 09:07:26] vc-utils.c(934): File C:/Users/path/xyz2.eml is changed. Skip removing the file.
[04/06/18 09:07:26] repo-mgr.c(5870): File path/xyz.eml is changed, skip deleting it.
[04/06/18 09:07:26] repo-mgr.c(5870): File path/xyz2.eml is changed, skip deleting it.

I have this issue now for about a month. Clients are all 6.1.1 and above, Server is on version 6.2.9.
I also added an execption to our antivirus to ignore all eml files.

The only way, i get them removed, is to stop Seafile, remove the files on all clients and start it again.

The only thing i have changed is the Server. I had an old version of the Server running and Updated to 6.2.9. I don’t know if that has anything to do with this issue.


#14

Sorry, but I have to be a bit pushy. We still can’t delete any EML file.
Our Anti-Virus is Ignoring all EML files but still it gets always recreated after a client reboots/starts.



These are only three examples. I could post a lot more.
I delete the content of a Folder with EML files (no matter if from my Client or the Web Interface) and as soon as a new client starts and checks the files, it recreates it. Diverent user with diverend versions of Seafile. But always above 6.1.1 (Win 7 and 10).

Always the same error message in the log files. File has changes blabla
Is there anything i could do?


#15

Hi @Andre

This is a side effect of the fix for the previous issue. We’ll include a fix to it in the next release. For now it’s not easy to remove .eml files.