在新设备上一直同步失败

同步下载方向应该是有断点续传的，失败以后点继续重试看看。

但是我同步失败之后，同步按钮就点不了了：

只能关了再开，这时候又从 0 开始下载

而且，软件内下载时下载失败会有弹窗显示异常消息，重启后再下载也就是启动界面上下载时，不会提示消息，就是一直卡着，什么也不显示，像下面这样就一直卡在 10000 处不动：

打包来一发日志。

刚刚把之前新建的工作空间全删了重新搞，这一次是刚打开时同步失败，错误信息和帖子中相同，同步失败后，和刚才帖子中说的一样点击同步按钮没有反应，只能关掉重新打开思源，重新同步时从 0 开始同步而不是从之前的位置开始，然后这次一口气同步成功了。

前面的日志被我删掉了，刚才的日志：

siyuan.zip

以及，在新设备上下载时，我是否可以手动离线拷贝 data 文件夹，然后在新设备上点击同步，这样会出问题吗？

理论上应该是断点续传，稍后我们分析下日志。

如果数据量较大，直接复制 data 文件夹到新设备上应该是可行的，如果是移动端的话可以用导出 data.zip 再导入。

还有个问题，同步成功后，我什么也没修改，直接关掉思源，这时候一直显示数据同步中，已经等了好几分钟了还是这样，照理来说我什么也没修改不需要等那么久吧：

第二次打开再关闭时正常

还发现一个问题，刚下载完时，不会自动重建索引，导致我发现很多功能有异常，结果发现 db 文件只有几十 k，还需要手动重建索引

断点续传的问题我用断网模拟了一下似乎没问题。

http2: server sent GOAWAY and closed the connection; LastStreamID=1999, ErrCode=NO_ERROR, debug="" 这个报错有点不好重现，可能是七牛云的前置机发出正常的连接关闭，思源 HTTP 客户端认为是个报错。我搜了一下，好像 NO_ERROR 可以认为不是报错，直接重试请求就行，下个版本我们改了看看 Issue #5314 · siyuan-note/siyuan

正常情况下同步下载完会重建索引的，这次没重建暂时不清楚为啥。你开了数据仓库吗？开了的话同步前会做一次快照，第一次快照需要时间比较久。

前面说的关闭时一直卡在“数据同步中”时候的日志：

I 2022/06/28 22:27:36 serve.go:78: kernel is booting [http://127.0.0.1:6806]
I 2022/06/28 22:27:36 sync.go:107: sync before boot
I 2022/06/28 22:38:20 sync.go:587: sync data to workspace data elapsed [218931ms]
I 2022/06/28 22:38:24 sync.go:393: sync [cloud=324841, local=0, fetchedFiles=14112, transferSize=2.3 GB] downloaded in [645.41s]
I 2022/06/28 22:38:39 conf.go:523: database size [74 kB], block count [146362]
I 2022/06/28 22:38:39 working.go:139: kernel booted
I 2022/06/28 22:42:29 sync.go:110: sync before exit
W 2022/06/28 22:46:04 sync.go:77: sync has been locked
W 2022/06/28 22:46:34 sync.go:77: sync has been locked
I 2022/06/28 22:46:56 sync.go:617: workspace data to sync data elapsed [267574ms]
I 2022/06/28 22:46:59 sync.go:278: sync [cloud=324841, local=325136, wroteFiles=3, transferSize=2.4 MB] uploaded in [3.05s]
I 2022/06/28 22:47:00 conf.go:362: exited kernel
E 2022/06/28 22:47:01 block_query.go:629: sql query [SELECT * FROM blocks WHERE id IN ()] failed: sql: database is closed
E 2022/06/28 22:47:01 block_query.go:37: sql query failed: SELECT id, hash FROM blocks WHERE root_id = ?%!(EXTRA *errors.errorString=sql: database is closed)

应该是因为复制数据（sync data to workspace data 和 workspace data to sync data）太耗时了，第一次同步的话估计只能这样，这个复制后面是增量的。

呃，之前说的 GOAWAY NO_ERROR 问题代码实现已经做过重试请求了……这问题看来暂时无法解决，先关闭了。