~/tosaki
返回

Kindle 个人文档不同步：坏的是本地数据库

约 17 分钟
编辑此页

目录

设备：Kindle Paperwhite 12 代 Signature Edition，Véra 越狱 + KOReader。出问题时固件 5.19.6，修完时是 5.20.1.0.2。

修复脚本与原理笔记：t0saki/kindle-cc-db-repair

风险提示：本文涉及越狱、以 root 删除系统数据库、调用未公开的系统接口。它只是我这一台设备上的记录，不是官方方案。动手前请先备份，并读完「动手之前」一节。

我的 Kindle 有好几个月处在一种半坏的状态。Send to Kindle 推过去的个人文档经常收不到；自动同步基本不工作，只能手动点；「同步到最远阅读页」一点就失败；已经下载的个人文档，长按菜单里没有「从设备移除」，只有「永久删除」。

同一个 Wi-Fi 下，手机上的 Kindle App 一切正常。我去 Reddit 和书伴翻了一圈，类似的抱怨很多，于是认定这是亚马逊的通病。期间我在路由器的广告过滤里给 Kindle 的同步域名加过白名单。没有效果。

之后我开始规划退路：阅读全部搬到 KOReader，书库用网页管理，传书走 OPDS，不再依赖亚马逊的同步。方案很完整，只是一直没动手。

11 月 11 日晚上又一次同步失败之后，我想起来一件事：这台 Kindle 早就越狱了，我有 root，可以直接看日志。想起这件事花了我几个月。

那天从晚上十点多到凌晨三点，我让 Claude Code（下文叫 Agent）先后 SSH 进了路由器和 Kindle。结论是：亚马逊的服务器每次都正常返回了 HTTP 200，家里的网络也没有问题，坏的是 Kindle 本地的书库数据库 /var/local/cc.db。点一次同步，它报了 398 次 SQL logic error。把它删掉让系统重建，同步就好了；再借系统自带的下载接口，把 1,166 本书的「已下载」状态重新登记回来，正文没有重新下载。

如果你是搜症状来的，看前两节就够。第三节是那天晚上的完整经过，包括在路由器上白查的半小时、一次计划外的固件升级，以及 11 GB 我早就删掉的漫画是怎么回来的。

一、先对症状：为什么它看起来像网络问题

如果是同一个故障，下面这些现象会同时出现，或者至少出现几条：

界面上看到的实际发生的
邮件 / Send to Kindle 新推的文档不出现，搜也搜不到云端已经下发了列表，写入本地 cc.db 时失败，新书库拿不到条目
「同步到最远阅读页」失败同一个故障的连带后果，重建数据库后恢复正常（具体卡在哪一步我没细查）
已下载的个人文档长按只有「永久删除」，没有「从设备移除」本地文件挂不上云端记录，系统只能把它当成侧载进去的本地文件
删掉一本书，空间腾出来了，但它仍被算作「已下载」文件删成功了，更新数据库的那一步失败了，记录留了下来
同一个 Wi-Fi 下，手机 Kindle App 完全正常手机 App 用的是手机自己的数据库。它只能证明账号和云端没问题

最后一行是这件事最有迷惑性的地方。手机好、Kindle 坏，谁都会先怀疑网络。

如果你的 Kindle 已经越狱，半分钟就能确诊。在原生界面点一次「同步并检查新内容」，然后执行（或者直接跑仓库里的 sh scripts/diagnose.sh）：

grep -c 'SQL logic error' /var/log/messages
grep 'ProcessArchiveItemFailed' /var/log/messages | tail -1

看到下面这两类报错，就不用再查路由器和 DNS 了：

java[...]: E rc:lwsf:http_code=400,handler=process_/change,... /usr/lib/ccat/change.lua:1969: {"http_status_code":400,"sqlite3_msg":"SQL logic error","sqlite3_code":1}
java[...]: E ... /usr/lib/ccat/change.lua:2321: {"sqlite3_msg":"SQL logic error","sqlite3_code":1}
archive[...]: E archive:ProcessArchiveItemFailed:errorMsg=nullResponse,cdeKey=<private>,cdeType=PDOC,...,action=insert:
archive[...]: W archive:ProcessArchivedItemsUpdateCCatFailed:reason=updateCCATFailed

一个报错为什么会带出这么多症状，要看一眼现在 Kindle 里的两套书库数据库：

Kindle 双书库同步链路与 cc.db 写入故障

  1. /var/local/cc.db（旧书库）：归 ccat 管，这是一个跑在 Java 框架里的 Lua 服务。核心表 Entries 里，云端条目（p_isArchived=1）和已下载的本地副本（p_isArchived=0，p_location 指向文件路径）各占一行。
  2. /var/local/ksdk.asset.db（新书库）：归新版书库界面 KPPMainApp 管。屏幕上的书目和「已下载」标记，读的是它的 Nodes 表（DOWNLOAD_STATE 字段）。

两边靠挂在 cc.db 上的一串触发器保持同步：Entries 一有变动，触发器就调用 /usr/lib/ccat/sql_functions.lua 里的函数，把变更写进 CatalogChanges 和 AuditLog，新书库再照着日志跟进。

同步时，archive 进程从亚马逊拉回 archivedItems.xml（HTTP 200，内容完整），ccat 对每份个人文档先按 UUID 删旧行（change.lua:1969），再插新行（change.lua:2321）。在我这个坏掉的 cc.db 上，两步都报 SQL logic error：一次同步，36 次删除失败，362 次插入失败。源头写不进去，后面的链条就没有东西可同步，界面上自然什么都看不到。

二、怎么修

动手之前

这一节的操作包括：越狱，以 root 删除系统数据库，重启，批量调用亚马逊没有公开的内部接口。每一项都可能出问题，其中几项我自己就出了，第三节有记录。

  • 这是一台设备上的记录。 型号和固件见文章开头。换一个型号或固件，文件路径、接口名、数据库结构都可能不一样，亚马逊也随时可以改掉其中任何一项。
  • 先备份，备份两份。 设备上一份，电脑上一份，确认电脑上那份拷完整了再往下走。至少包括 /var/local/ 下的 cc.db 和 ksdk.asset.db（backup.sh 会做这件事）。重要的书和旁边的 .sdr 目录（笔记和阅读进度）建议也单独拷一份。
  • 重建数据库会丢东西。 「已下载」状态一定会丢，后面讲怎么找回来。只存在本地、没同步到云端的收藏夹可能也会丢，我没有逐项核对重建前后的差异。
  • 越狱有它自己的风险。 可能失败，可能影响保修，也可能被一次系统更新带走。
  • 脚本没有完整重测。 仓库里的 scripts/ 是我事后根据当晚实际跑的命令整理的，逻辑一致，但整理之后没有在设备上从头到尾再跑一遍。请先读一遍再执行，任何批量操作先拿一本书试。
  • 最坏的情况是需要恢复出厂设置，所有内容重新下载。能接受这个结果再开始。

仓库是 MIT 许可，不带任何担保。照着做造成的数据丢失或设备问题，需要你自己承担。

1. 没有越狱

数据库在 /var/local/ 下面，USB 连接看不到，没有 root 碰不了。我的脚本帮不上忙，剩下两条路。

恢复出厂设置（我没有验证过）。 重置会把数据库清掉重建，按道理能解决。代价是设备上的内容全部清空，要重新下载，所以重置前请先把重要文件拷出来。

它管不管用，网上的反馈并不一致。书伴 5.18.5.0.1 固件更新帖的评论区里，2025 年 10 月有人（固件 5.18.4.0.1）遇到全部书籍和词典从界面上消失、连上电脑却看到文件都在的情况，同步、重启、注销再注册都没用，最后恢复出厂设置修好了。同一个楼里也有人说，重置、重新注册、重新导书之后问题照旧。他们的故障未必和我的是同一个，仅供参考。

先越狱，再按下一小节做。 好处是设备上已有的文件不用重下。入口是社区维护的 Kindle Modding Wiki，从 Jailbreaking Wizard 进去，它会按型号和固件带你到对应的方法。我用的是 Véra，之后装了 KOReader，它自带 SSH 服务器。两点提醒：

  • 越狱方法和固件版本绑得很死，先在 Wizard 里确认你的版本受支持。我在 5.20.1.0.2 上跑 Véra 成功了，但这只是一台设备的结果，教程列出的版本并没有覆盖到它。
  • Véra 的教程提醒过，要删掉根目录里的 .bin 更新包。请照做。Véra 屏蔽的是菜单入口和 OTA，开机时安装根目录里的更新包不在屏蔽范围内。这一点我是通过实验知道的。

2. 已经越狱：重建数据库，再把「已下载」找回来

脚本在仓库 t0saki/kindle-cc-db-repair 的 scripts/ 里。整体流程：

修复与恢复流程

把 scripts/ 拷到 Kindle 上（比如 /mnt/us/ccdb-repair/scripts/）。在 macOS 上传文件用 OpenMTP 或 Android File Transfer 就行。不要用 libmtp 的 mtp-detect：它会把设备属性挨个探测一遍，Agent 试了两次，两次都把 Kindle 踢出了 MTP 模式。

准备：一个退回原生界面也不会断的 SSH

KOReader 自带的 SSH（端口 2222）跟着 KOReader 走，一退出就断。而后面的同步和批量恢复必须在原生界面下进行，因为 KOReader 启动时会停掉原生框架。办法是先连上 2222，用 KOReader 自带的 dropbear 在 2223 端口另起一个：

cd /mnt/us/koreader && setsid ./dropbear -E -R -s -p 2223 -P /tmp/dropbear_2223.pid

它只接受公钥登录，读的是同目录下的 settings/SSH/authorized_keys。起好之后退出 KOReader 回到原生主页，改连 2223，以下操作都以 root 执行。

第 0 步：诊断和备份

sh scripts/diagnose.sh
sh scripts/backup.sh

backup.sh 把两个数据库备份到 /mnt/us/ccdb-repair/backup-<时间>/。把这个目录再往电脑上拷一份，然后再继续。 这不只是保险：后面恢复「已下载」要用到旧的 cc.db，它是唯一还记着你下载过哪些书的地方。

第 1 步：重建

sh scripts/reset-ccdb.sh

⚠️ 重启前，/mnt/us/ 根目录里不能有 *.bin 固件包。 脚本会检查，发现了就拒绝执行；没有备份过它也会拒绝。

脚本把 cc.db 挪走并重启。开机连上 Wi-Fi 后，云端书目会陆续回到书库里。这时推一篇新文档、同步一下进度、长按看看菜单，原来的故障到这里就已经修好了。

然后你会发现「已下载」是 0。

文件都还在。去 /mnt/us/documents/Downloads/Items01/ 看一眼，.kfx 正文和 .sdr 目录一个没少，我这台有大约 7,800 个文件。显示为 0 有两个原因：删掉 cc.db 时，下载状态也被同步清空到了新书库里，全部变成 NOT_DOWNLOADED；而负责扫描本地文件的 scanner 不管 Downloads/ 目录，全盘扫描的结果是 fullscan:OK:add=0。那里的文件只在下载完成的那一刻登记一次，等多久都不会自己回来。

第 2 步：用旧库生成清单

sh scripts/build-restore-list.sh /mnt/us/ccdb-repair/backup-XXXX/cc.db

它从旧库里取出所有标着「已下载」的条目，逐条检查文件还在不在。在的进 restore.list，不在的进 stale.list。后者不要恢复，原因见下文。

第 3 步：批量恢复，核对补漏

# 后台批量调用官方下载接口，断开 SSH 也会继续跑
setsid sh scripts/restore-downloads.sh </dev/null >/dev/null 2>&1 &
tail -f /mnt/us/ccdb-repair/restore.log

这一步没有去改任何数据库，而是调用了书库里「下载」按钮背后的同一个接口：

echo '{ kppItems = "CDEKEY,PDOC;CDEKEY2,PDOC" }' | lipc-hash-prop com.lab126.readnow kppDownloadAction

文件已经在设备上时，这个调用内部是这样的：

kppDownloadAction 在本地文件已存在时的调用链

每本书只重新拉一份大约 2.8 KB 的清单。到正文请求时，服务器返回 HTTP 304 Not Modified，传输 0 字节。本地 .kfx 的修改时间不变，旁边 .sdr 目录里的阅读进度和批注原样保留。最后由 ccat 自己把下载记录写进 cc.db，再同步给新书库。

我这台的速度是每分钟 15 到 20 本，一千本大约一个小时。期间注意三件事：

  1. 停在原生主页，插着电，Wi-Fi 别断。
  2. 不要打开 KOReader。下载队列存在原生框架的内存里，框架一停，队列就没了。
  3. 脚本会临时禁用屏保，并在 /var/log/messages 太大时自动清空它，防止写满 64 MB 的 /var。

跑完之后核对一遍，把没登记上的和卡在「下载中」的再提交一次：

sh scripts/verify.sh
rm /mnt/us/ccdb-repair/restore.offset
setsid sh scripts/restore-downloads.sh /mnt/us/ccdb-repair/retry.list </dev/null >/dev/null 2>&1 &

三件不要做的事

  • 不要恢复 stale.list。 这些条目在旧库里标着「已下载」，文件却不在了。它们不是丢失的文件，而是数据库坏掉期间你自己删过的书：文件删成功了，记录没删掉。把它们提交上去，本地没有文件，304 不成立，Kindle 会认真地把它们从云端重新下载一遍。
  • 不要用 sqlite3 命令行改 cc.db。 Entries 表的索引用了自定义的 COLLATE icu，触发器要调用 ccat 内部的 Lua 函数，命令行工具里这两样都没有。写进去不会报错，但索引已经乱了。查进度请只读打开，也不要把数据库拷到 /tmp： 
    sqlite3 "file:/var/local/ksdk.asset.db?mode=ro" "select DOWNLOAD_STATE,count(*) from Nodes group by 1;"
  • 不要把 lipc-probe -v com.lab126.kppkaf 的输出贴到任何地方。 它会明文打印你的亚马逊访问令牌。

另外记一笔：Agent 还反编译了 DeleteItemHandler，查到移除本地下载的调用格式是 echo '{ kppCdeKey = "CDEKEY", kppCdeType = "PDOC" }' | lipc-hash-prop com.lab126.readnow kppDeleteItemAction，只要不传 kppFrom = "cloud"，就不会走到撤销云端试读本的分支。这条命令我没有实际执行过，要用请先拿一本书试。更多细节在仓库的 docs/how-it-works.md 里。

三、那天晚上

上一节写出来是四步。实际从晚上十点多做到了凌晨三点。

1. 先查了网络

我平时看书分两头：EPUB 用 KOReader，推送的个人文档用原生系统。几个月前原生这边开始出问题，我去 r/kindle 搜 sync issue，近几个月的求助帖能翻出一长串，比如 my kindle isn’t syncing! someone help me? 和 Usually syncs only one way。书伴固件更新帖的评论区里，有人说升级后书都打不开、显示已删除，可文件还在存储里；有人说书和词典全部消失，「手动删除」里什么都没有，空间却照样占着。

我没法确认这些人和我是不是同一个原因。但当时看完，我接受了「这是亚马逊的问题」这个结论，然后忍了几个月。

所以那天晚上我给 Agent 的第一句描述是这样的：

连家里 Wi-Fi 就不同步，连手机热点好像没事；同一个 Wi-Fi 下手机 Kindle App 是正常的。

任何人听到这句话都会去查网络。我家的网络也确实值得一查：软路由上跑着代理、35 万条规则的广告过滤，还开着软硬件流量卸载。

Agent 在路由器上逐项排除。Kindle 不在代理名单里，流量是直连的。广告过滤列表里有一大片 amazon 域名，但 Kindle 同步用到的那几个（todo-ta-g7g、cde-ta-g7g、det-ta-g7g、kindle-digital-delivery）早就在白名单里了。那是我几个月前为了这个同步问题亲手加的。加了，没用。现在我知道为什么了。

然后是抓包。Agent 在网桥 br-lan 上抓，看到的现象很像一回事：每条连接 TCP 握手都成功，之后客户端不发 TLS ClientHello，12 秒后服务器发 FIN 断开。怎么看都是 TLS 被什么东西拦了。

实际上是抓包的位置不对：

流量卸载下，在网桥上抓包只能看到握手

路由器开着流量卸载，flowtable 挂在物理网口的 ingress 上。连接一旦建立，后续的包就在两个物理口之间直接转发，不再经过 br-lan。在网桥上只能看到开头和结尾那几个包，中间的数据不是没发，是没从这里走。

Agent 在不重载防火墙的前提下临时摘掉卸载规则，换到物理口 eth2 上重抓。这次 TLS 1.3 握手完整，双向数据收发正常，而 Kindle 照样同步失败。

到这里可以确定，家里的网络没有问题。这个结论是对的，只是对修 Kindle 没什么帮助。至于「连热点好像没事」，已经没法复测了。数据库写入失败不看网络，所以它多半只是我的一个印象。

2. 日志

接下来只能进设备。我用 OpenMTP 把公钥放进 koreader/settings/SSH/authorized_keys（在这之前 Agent 先用 mtp-detect 把 Kindle 踢出了两次 MTP 模式），连上 2222。

/var/log/messages 里最先看到的是另一个干扰项：下载服务 tmd 有一串来自 AmazonS3 的 srv=403。对了一下时间戳，这批请求 23:03 进的队列，23:10 Wi-Fi 连上才发出去，预签名链接已经过期了。

再同步一次，403 没有了，剩下的就是第一节贴过的那 398 条 SQL logic error。这时我才顺口提了一句「对了，下载的个人文档长按只有永久删除」，和日志正好对上：文档没能登记成云端条目，系统只能把它当本地文件。

Agent 试着往下查具体是哪条 SQL 出的错。它用 KOReader 自带的 LuaJIT 和 ljsqlite3，在数据库副本上给那些 Lua 函数打了桩，配了一个按字节比较的 icu 排序规则，重放那条失败的 DELETE。结果报 database disk image is malformed（779，SQLITE_CORRUPT_INDEX），REINDEX 之后又好了。也就是说，这个「损坏」只是测试用的排序规则和 Kindle 的不一致造成的假象，触发器链本身没有问题。至于真机上到底是什么触发了 SQL logic error，ccat 只打印了一句通用的错误描述，真正的原因没留下来。

晚上十一点半，我们决定不再往下挖：备份 cc.db，删掉，reboot。

3. 重启，以及一次计划外的升级

重启之后回来的不是书库，是固件更新。

当晚早些时候，我本来打算把固件升到 5.20.1 再重新越狱，就把更新包拷进了 Kindle 根目录。拷完才发现，越狱后的设置里根本没有「更新您的 Kindle」这一项：Véra 为了屏蔽更新，把 /usr/bin/otaupd 和 otav3 改了名。我放弃了升级，文件留在了原地。

Agent 在 reboot 之前没有检查 /mnt/us/，我也没想起来提醒它。于是那个升级还是完成了，只是比原计划晚了一点。

固件到了 5.20.1，越狱没了，OTA 屏蔽也跟着没了。我在原生界面等书目同步的那二十来分钟里，它又自己升到了 5.20.1.0.2。

Véra 的教程没有列出这个版本。我照流程重跑了一遍，成功了。

重新连上 SSH：SQL logic error 是 0，ProcessArchiveItemFailed 是 0，OTA 屏蔽重新生效。新推的文档出现了，进度能同步了，长按菜单里「从设备移除」回来了。几个月的问题，到这里结束。

4. 「已下载」归零

然后我看了一眼「已下载」：0 本。

一千多本书的文件都在设备上，书库不认。我当时说，要不干脆恢复出厂设置算了。Agent 指出，重置一样会丢下载状态，而且文件也会一起没了，结果只会更差。

怎么让新数据库重新认领这些文件？手动点「下载」是好使的，所以 Agent 让我随便点一本当样本，它在后台看日志。有两个发现：

  1. 点「下载」最终调用的是 com.lab126.readnow 上的 LIPC 属性 kppDownloadAction。
  2. 样本的正文请求返回 srv=304，0 字节。本地 .kfx 的修改时间还是 10 月 3 日，全程只重新拉了 2.8 KB 的清单。

Agent 从 /opt/amazon/ebook/lib/EInkReadNowService.jar 里取出 DownloadActionHandler，用 javap 反编译，确认参数格式是 cdeKey,cdeType;...。拿一本书试，登记成功。旧库里标着「已下载」的一共 1,296 条，每批 20 本、间隔 45 秒，后台开跑。

5. 后面还出了三次状况

内存盘写满。 Kindle 的 /var 是一个 64 MB 的内存盘，/tmp 也在里面。批量下载时 /var/log/messages 每分钟涨大约 4 MB，11 分钟到了 48 MB。Agent 为了查进度，还往 /tmp 里拷了数据库副本，/var 于是到了 100%。处理办法是清空日志，加一个超过 12 MB 就清空的守护循环，查库改成只读直接打开。

清理后台进程时，Agent 用了 pkill -f 和 ps | grep，匹配串正好也出现在它自己的 SSH 命令行里。它三次杀掉了自己的会话，之后改用 PID 文件。中间它还重跑了一次旧版的恢复脚本，把刚整理好的待办清单覆盖了。

我打开了 KOReader。 跑到一半，我点开了 KOReader。原生框架随即停止，下载队列随之消失，2223 端口的 SSH 也断了，新书库里留下 126 条卡在 DOWNLOADING 的记录。回到原生界面重新起 SSH，算出「旧库清单减去已登记的」，再加上卡住的条目，分两轮补交了 182 本和 49 本。上一节的注意事项第 2 条，来源就是这里。

11 GB 漫画。 补交的过程中，我发现存储满了。

下回来的全是漫画，而且是我以前删掉的漫画。

那 1,296 条记录里，文件还在的是 1,166 条，另外 130 条的文件已经不在了。Agent 生成清单时其实查到了这一点，但把它理解成「文件丢了，需要补下」，一并提交了。事实是：cc.db 坏掉的那几个月里，我在界面上删书，文件删掉了，数据库没更新成功，这 130 条「已下载」就一直留在旧库里。本地没有文件，304 自然不成立，系统老老实实地下了大约 11 GB。

我在原生界面里把这批手动删了。顺便得到一个验证：删掉其中 12 本之后，文件消失，数据库记录同步更新，没有 SQL 报错。新库的删除也是正常的。

凌晨三点收工时的账：

修复前收工时
一次同步的 SQL logic error398 次（36 删 + 362 插）0 次
找回的「已下载」—1,166 本（新书库里共 DOWNLOADED=1189）
找回它们重下的正文—没有（HTTP 304，只拉 KB 级的清单）
不该恢复却恢复了的旧库残留 130 条真下载约 11 GB，手动清理后剩余 13.3 GB
固件5.19.65.20.1.0.2（未经本人同意）

收尾时还有大约 19 本停在 DOWNLOADING，基本是那批被打断的漫画，没有再管。

四、教训，和没解开的问题

  1. 能看设备自己的日志，就先看日志。 抓包能证明数据到了设备，证明不了设备把它处理好了。路由器上那半小时把网络彻底排除了，也顺带弄清了流量卸载的抓包盲区，不算白费。但如果先看 /var/log/messages，十分钟就够了。
  2. 「换个网络好像就好了」需要复测。 本地 SQLite 报错不会区分 Wi-Fi 和热点。我把一个没验证过的印象当成事实告诉了 Agent，前半场的方向就是这么定下来的。
  3. 症状相似的抱怨，原因可能完全不同。 看到到处有人说同步坏了，我就默认是服务端的通病。别人的设备我没有日志，无从判断。但我这一台，问题完全在本地，而且能修。差一点，我就为了一个可以删掉重建的文件换掉整套阅读方案。
  4. 坏掉的数据库，里面的记录也不可信。 旧库不只是没记上新书，连我删过什么也没记上。「标着已下载、文件却不在」是一个很明确的信号，当时看到了，读错了。现在的 build-restore-list.sh 会把这类条目单独隔离。
  5. 能走官方的代码路径，就不要手改数据库。 那天晚上最稳的一个决定是没有去动 cc.db，而是找到 kppDownloadAction，让系统自己写。慢一些，但写进去的东西和正常使用时完全一样。
  6. 让 Agent 操作真实设备，备份和小步验证是前提。 弄清两套书库的关系、从 jar 包里反编译出接口参数、发现 304 这条路，这些我自己做大概要花几个周末。它也在重启前没检查根目录，往 64 MB 的内存盘里拷数据库，把过期记录当成待恢复的书，并且三次杀掉了自己的会话。我能放手让它做，是因为动手前有两份备份，每个批量操作都先拿一本书试过，而且我一直在旁边看着。那 130 本的来历，最后是我自己认出来的。

还有两件事没有答案：

  • cc.db 最初是怎么坏的。 可能和 5.19 引入的新旧书库双写迁移有关，可能是两个数据库并发写入时出了问题（日志里出现过 3 次 database is locked），也可能和往书库里写条目的第三方插件有关。都只是猜测，没有证据。删库重建解决了现在的问题，我不知道它以后会不会再来。
  • 连热点时到底正不正常。 数据库已经重建，没法验证了。

如果你的 Kindle 上也有同样的 change.lua / SQL logic error 日志，尤其是定位到了具体原因，欢迎到 t0saki/kindle-cc-db-repair 提 issue。

参考

编辑此页
分享这篇文章：
Sina Weibo分享到 Weibo QQ分享到 QQ Qzone分享到 Qzone 分享到 Whatsapp 分享到 Facebook 分享到 X 分享到 Telegram 分享到 Pinterest 通过邮件分享

下一篇
Q3 随手拍