I wonder if there is any potential Issue on libraries synced from a DFS user folder.
The user files are on the Active Directory Server and shared to any user.
The local PC works on a local cache that is synchronized with the server. (windows sync)
Everything worked files on a 8.9 GB library since i deleted 1Gb of files on the local cache.
Now the seafile sync client stop synchronizing and the log tells :
Then the process hangs on indexing files so i can set the option (1 second)
But the seafile.log traces errors
[11/13/17 10:53:47] vc-utils.c(165): Failed to update index errno=13 Permission denied
[11/13/17 10:53:47] vc-utils.c(165): Failed to update index errno=13 Permission denied
[11/13/17 10:53:48] vc-utils.c(165): Failed to update index errno=13 Permission denied
[11/13/17 10:53:49] vc-utils.c(165): Failed to update index errno=13 Permission denied
[11/13/17 10:53:49] vc-utils.c(165): Failed to update index errno=13 Permission denied
[11/13/17 10:53:50] vc-utils.c(165): Failed to update index errno=13 Permission denied
[11/13/17 10:53:51] vc-utils.c(165): Failed to update index errno=13 Permission denied
[11/13/17 10:53:52] vc-utils.c(165): Failed to update index errno=13 Permission denied
[11/13/17 10:53:52] vc-utils.c(165): Failed to update index errno=13 Permission denied
[11/13/17 10:53:53] vc-utils.c(165): Failed to update index errno=13 Permission denied
[11/13/17 10:53:54] vc-utils.c(165): Failed to update index errno=13 Permission denied
[11/13/17 10:53:55] vc-utils.c(165): Failed to update index errno=13 Permission denied
[11/13/17 10:53:55] vc-utils.c(165): Failed to update index errno=13 Permission denied
The database seems locked :
[11/13/17 10:54:10] http-tx-mgr.c(1132): Transfer repo '022257ce': ('normal', 'data') --> ('finished', 'finished')
[11/13/17 10:54:10] wt-monitor-win32.c(565): GetQueuedCompletionStatus failed, error code 87[11/13/17 10:54:10] clone-mgr.c(847): Transition clone state for 022257ce from [fetch] to [done].
[11/13/17 10:54:10] SQL error: 5 - database is locked
: DELETE FROM CloneTasks WHERE repo_id='022257ce-5b1f-487f-a8c2-6af5ab5c6c02'
The sync process ends with Success, whereas the database is still locked :
[11/13/17 10:55:02] sync-mgr.c(702): Repo '_Projets' sync state transition from 'synchronized' to 'committing'.
[11/13/17 11:00:30] repo-mgr.c(3728): All events are processed for repo 022257ce-5b1f-487f-a8c2-6af5ab5c6c02.
[11/13/17 11:00:54] sync-mgr.c(702): Repo '_Projets' sync state transition from 'committing' to 'uploading'.
[11/13/17 11:00:54] http-tx-mgr.c(3423): Upload with HTTP sync protocol version 1.
[11/13/17 11:00:54] http-tx-mgr.c(1132): Transfer repo '022257ce': ('normal', 'init') --> ('normal', 'check')
[11/13/17 11:00:54] sync-mgr.c(702): Repo '_Info' sync state transition from 'synchronized' to 'committing'.
[11/13/17 11:00:55] http-tx-mgr.c(1132): Transfer repo '022257ce': ('normal', 'check') --> ('normal', 'commit')
[11/13/17 11:00:55] http-tx-mgr.c(1132): Transfer repo '022257ce': ('normal', 'commit') --> ('normal', 'fs')
[11/13/17 11:00:55] http-tx-mgr.c(1132): Transfer repo '022257ce': ('normal', 'fs') --> ('normal', 'data')
[11/13/17 11:00:59] http-tx-mgr.c(1132): Transfer repo '022257ce': ('normal', 'data') --> ('normal', 'update-branch')
[11/13/17 11:00:59] http-tx-mgr.c(1132): Transfer repo '022257ce': ('normal', 'update-branch') --> ('finished', 'finished')
[11/13/17 11:00:59] sync-mgr.c(702): Repo '_Projets' sync state transition from 'uploading' to 'initializing'.
[11/13/17 11:00:59] sync-mgr.c(1516): Removing blocks for repo _Projets(022257ce).
[11/13/17 11:01:00] SQL error: 5 - database is locked
: REPLACE INTO Config VALUES ('notify_sync', 'on');
[11/13/17 11:01:26] sync-mgr.c(702): Repo '_Info' sync state transition from 'committing' to 'initializing'.
[11/13/17 11:01:26] sync-mgr.c(702): Repo '_Projets' sync state transition from 'synchronized' to 'committing'.
It could be. To fix it place the Seafile directory out of DFS. There is a hidden directory which is heavily being used. You can still sync libraries on DFS.
I did as you told me and placed the Seafile directory on a local drive not SYNCED With DFS.
I do not encounter any problem anymore.
I think that it could be mentioned during the client Installation process and on the manual.
Actually, there is not a lot of information no best pratices about the client.
I’m pretty sure the issues involved in such a setup have been discussed multiple times. Inotify (a mechanism to get notified when a file changed) does not work with CIFS/DFS, thus the client needs to rescan the whole library over and over again (using the sync interval). That can be a resource hungry process and is likely going to take more and more time the more files there are.
This is exactly what happens. And it could also be the reason why the process is so long on huge libraries (>5Go).
Tiis is a major issue for us. I hope this can be fixed in future releases of the client, but i’m not very optimitic.
Are you, @daniel.pan ?
The client has to scan all the folder, checking the timestamp for all the files. It does not read the actual file content. So the performance depends on the number of files. This can’t be improved in the future.
It is not really the case. It is still the client which is syncing. In the best case synchronization always happens from the machine the disk is in. The client was always developed to synchronize local file systems.