Failed to upgrade from 5.1.4 to 6.0.4

Server running seafile 5.1.4 with sqlite, when running ./upgrade_5.1_6.0.sh I get:

===================
This script would upgrade your seafile server from 5.1 to 6.0
Press [ENTER] to contiune

Updating seafile/seahub database …

[INFO] You are using SQLite3
[INFO] updating seahub database…
Traceback (most recent call last):
File “/var/sifail/seafile-server-6.0.4/upgrade/db_update_helper.py”, line 362, in
main()
File “/var/sifail/seafile-server-6.0.4/upgrade/db_update_helper.py”, line 357, in main
db_updater.update_db()
File “/var/sifail/seafile-server-6.0.4/upgrade/db_update_helper.py”, line 258, in update_db
super(SQLiteDBUpdater, self).update_db()
File “/var/sifail/seafile-server-6.0.4/upgrade/db_update_helper.py”, line 120, in update_db
self.update_seahub_sql(seahub_sql)
File “/var/sifail/seafile-server-6.0.4/upgrade/db_update_helper.py”, line 282, in update_seahub_sql
self.apply_sqls(self.seahub_db, sql_path)
File “/var/sifail/seafile-server-6.0.4/upgrade/db_update_helper.py”, line 272, in apply_sqls
conn.execute(line)
sqlite3.OperationalError: table base_filecomment has no column named author

Failed to upgrade your database

=======================

The upgrade fails.

This is the current structure of table base_filecomment:

==================
sqlite> .schema base_filecomment
CREATE TABLE “base_filecomment” ( “id” integer NOT NULL PRIMARY KEY, “repo_id” varchar(36) NOT NULL, “file_path” text NOT NULL, “file_path_hash” varchar(12) NOT NULL, “from_email” varchar(75) NOT NULL, “message” text NOT NULL, “timestamp” datetime NOT NULL);
CREATE INDEX “base_filecomment_ca6f7e34” ON “base_filecomment” (“repo_id”);

===================

I’ve just noticed the post in Upgrade 5.1 to 6.02 mysql error describing the same problem. The solution proposed was to drop the table and let the upgrade script re-create it.
That is acceptable if the table is empty. In our server the table is not empty, since 2013 it contains some entries.
Is there any way to migrate the contents of the old table to the new schema? @xiez @daniel.pan

The entry in the old table is not used since a long time ago. It is safe for you to remove them.