Pro 7.0.6: Warnings spammed in file_updates_sender.log

Anything I can do to get rid off those warnings:
/home/seafile/seafile-pro-server-7.0.6/pro/python/SQLAlchemy-1.1.3-py2.7-linux-x86_64.egg/sqlalchemy/dialects/mysql/ Warning: (1287L, u"'@@tx_isolation' is deprecated and will be removed in a future release. Please use '@@transaction_isolation' instead")


I just upgraded my test server to 7.0.7 (RedHat Linux) and my file_updates_sender.log is spammed with the following message:

Warning: File comment has changed since version 6.3, while table 'base_filecomment' is not migrated yet, please consider migrate it according to v6.3.0 release note, otherwise the file comment feature will not work correctly.

There is no information on the table base_filecomments in the upgrade scripts of 6.3.0. The latest entries are in the upgrade script of 7.0.0:

seahub.sql:ALTER TABLE base_filecomment ADD detail LONGTEXT DEFAULT NULL;
seahub.sql:ALTER TABLE base_filecomment ADD resolved TINYINT(1) NOT NULL DEFAULT 0;
seahub.sql:ALTER TABLE base_filecomment ADD INDEX resolved (resolved);

But my database has the changes, so I don’t understand the error message that appears every minute.

see here the ChangeLog:


In version 6.3, Django is upgraded to version 1.11. Django 1.8, which is used in version 6.2, is deprecated in 2018 April.

With this upgrade, the fast-cgi mode is no longer supported. You need to config Seafile behind Nginx/Apache in WSGI mode.

The way to run Seahub in another port is also changed. You need to modify the configuration file conf/gunicorn.conf instead of running ./ start <another-port>.

Version 6.3 also changed the database table for file comments, if you have used this feature, you need migrate old file comments using the following commends after upgrading to 6.3:

./ python-env seahub/ migrate_file_comment

Note, this command should be run while Seafile server is running.6.3

Well, this is not related to my initial question, is it?

No, @uosseafile highjacked the thread

1 Like

I apologize :flushed:
I thought it was related to your problem with spamming the file_updates_sender.log. It seems to be a different problem.

No worries, initially I had the same issue, too. But I could solve it on my own, only the other log entry remains.

You guys don’t have this entry in your logs?

Unfortunatedly I only use the CE Version (7.0.4)