数据库相关的错误

Tide Gu

Pro版本，安装在群辉NAS上，开始解析时报错，没来及复制下来，然后设置定时解析也报错：
Internal server error, (sqlite3.OperationalError) database is locked [SQL: SELECT sys_user.id AS sys_user_id, sys_user.username AS sys_user_username, sys_user.password AS sys_user_password, sys_user.nickname AS sys_user_nickname, sys_user.email AS sys_user_email, sys_user.current_session_id AS sys_user_current_session_id, sys_user.state AS sys_user_state, sys_user.create_time AS sys_user_create_time, sys_user.update_time AS sys_user_update_time FROM sys_user WHERE sys_user.username = ? LIMIT ? OFFSET ?] [parameters: ('~~xxx~~', 1, 0)] (Background on this error at: https://sqlalche.me/e/20/e3q8)

解析任务里逐条的都是好的，最后也报错：
2025-06-07 05:27:01.495 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - decryption file: /app/data/sessions/1/~~xxx~~/Msg/Multi/MediaMSG7.db
2025-06-07 05:27:01.616 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - decryption success, ready to write decrypted file
2025-06-07 05:27:06.056 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - write decrypted file success
2025-06-07 05:27:06.056 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - record file modification_time
2025-06-07 05:27:17.380 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - decryption file: /app/data/sessions/1/~~xxx~~/Msg/Multi/MediaMSG8.db
2025-06-07 05:27:17.509 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - decryption success, ready to write decrypted file
2025-06-07 05:27:25.199 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - write decrypted file success
2025-06-07 05:27:25.199 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - record file modification_time
2025-06-07 05:27:40.257 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - decryption file: /app/data/sessions/1/~~xxx~~/Msg/Multi/MediaMSG9.db
2025-06-07 05:27:40.346 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - decryption success, ready to write decrypted file
2025-06-07 05:27:40.715 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - write decrypted file success
2025-06-07 05:27:40.715 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - record file modification_time
2025-06-07 05:27:51.722 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - 数据库解密完成
2025-06-07 05:27:51.722 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - 开始数据库排序------------------------------------
2025-06-07 05:27:51.723 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - 没有获取到缓存的库排序，临时生成
2025-06-07 05:27:51.724 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - 数据库最大值 40
2025-06-07 05:27:51.724 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - 查询库 39
2025-06-07 05:28:06.871 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - ERROR - 任务执行异常
2025-06-07 05:28:06.871 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - ERROR - (sqlite3.OperationalError) no such table: MSG
[SQL: SELECT "MSG"."localId" AS "MSG_localId", "MSG"."TalkerId" AS "MSG_TalkerId", "MSG"."MsgSvrID" AS "MSG_MsgSvrID", "MSG"."Type" AS "MSG_Type", "MSG"."SubType" AS "MSG_SubType", "MSG"."IsSender" AS "MSG_IsSender", "MSG"."CreateTime" AS "MSG_CreateTime", "MSG"."Sequence" AS "MSG_Sequence", "MSG"."StatusEx" AS "MSG_StatusEx", "MSG"."FlagEx" AS "MSG_FlagEx", "MSG"."Status" AS "MSG_Status", "MSG"."MsgServerSeq" AS "MSG_MsgServerSeq", "MSG"."MsgSequence" AS "MSG_MsgSequence", "MSG"."StrTalker" AS "MSG_StrTalker", "MSG"."StrContent" AS "MSG_StrContent", "MSG"."DisplayContent" AS "MSG_DisplayContent", "MSG"."Reserved0" AS "MSG_Reserved0", "MSG"."Reserved1" AS "MSG_Reserved1", "MSG"."Reserved2" AS "MSG_Reserved2", "MSG"."Reserved3" AS "MSG_Reserved3", "MSG"."Reserved4" AS "MSG_Reserved4", "MSG"."Reserved5" AS "MSG_Reserved5", "MSG"."Reserved6" AS "MSG_Reserved6", "MSG"."CompressContent" AS "MSG_CompressContent", "MSG"."BytesExtra" AS "MSG_BytesExtra", "MSG"."BytesTrans" AS "MSG_BytesTrans"
FROM "MSG" ORDER BY "MSG"."localId" DESC
LIMIT ? OFFSET ?]
[parameters: (1, 0)]
(Background on this error at: https://sqlalche.me/e/20/e3q8)
2025-06-07 05:28:31.017 - 16574e26-79de-465d-9f1c-43c338c8a1e6 - INFO - 任务执行完成，花费时间: 1583.9592669010162s

Tide Gu

现在左侧列表能载入，但是非公众号的消息似乎都出不来，报错：
{ "detail": "Internal server error, (sqlite3.OperationalError) no such table: MSG\n[SQL: SELECT \"MSG\".\"localId\" AS \"MSG_localId\", \"MSG\".\"TalkerId\" AS \"MSG_TalkerId\", \"MSG\".\"MsgSvrID\" AS \"MSG_MsgSvrID\", \"MSG\".\"Type\" AS \"MSG_Type\", \"MSG\".\"SubType\" AS \"MSG_SubType\", \"MSG\".\"IsSender\" AS \"MSG_IsSender\", \"MSG\".\"CreateTime\" AS \"MSG_CreateTime\", \"MSG\".\"Sequence\" AS \"MSG_Sequence\", \"MSG\".\"StatusEx\" AS \"MSG_StatusEx\", \"MSG\".\"FlagEx\" AS \"MSG_FlagEx\", \"MSG\".\"Status\" AS \"MSG_Status\", \"MSG\".\"MsgServerSeq\" AS \"MSG_MsgServerSeq\", \"MSG\".\"MsgSequence\" AS \"MSG_MsgSequence\", \"MSG\".\"StrTalker\" AS \"MSG_StrTalker\", \"MSG\".\"StrContent\" AS \"MSG_StrContent\", \"MSG\".\"DisplayContent\" AS \"MSG_DisplayContent\", \"MSG\".\"Reserved0\" AS \"MSG_Reserved0\", \"MSG\".\"Reserved1\" AS \"MSG_Reserved1\", \"MSG\".\"Reserved2\" AS \"MSG_Reserved2\", \"MSG\".\"Reserved3\" AS \"MSG_Reserved3\", \"MSG\".\"Reserved4\" AS \"MSG_Reserved4\", \"MSG\".\"Reserved5\" AS \"MSG_Reserved5\", \"MSG\".\"Reserved6\" AS \"MSG_Reserved6\", \"MSG\".\"CompressContent\" AS \"MSG_CompressContent\", \"MSG\".\"BytesExtra\" AS \"MSG_BytesExtra\", \"MSG\".\"BytesTrans\" AS \"MSG_BytesTrans\" \nFROM \"MSG\" ORDER BY \"MSG\".\"localId\" DESC\n LIMIT ? OFFSET ?]\n[parameters: (1, 0)]\n(Background on this error at: https://sqlalche.me/e/20/e3q8)" }

likeflyme

参考：https://forum.cloudbak.org.cn/d/16-205-beta，这个beta 版本可以通过全量解析一次修复这个错误，否则需要手动操作。
手动操作参考：
https://www.cloudbak.org/questions.html#%E6%80%BB%E6%98%AF%E8%A7%A3%E6%9E%90%E5%A4%B1%E8%B4%A5%E6%88%96%E5%87%BA%E7%8E%B0-database-disk-image-is-malformed

Tide Gu

likeflyme 这个好像是非Pro版，那我能不能Pro和非Pro都装（群辉的docker），映射在同一个本地文件夹里，然后用非Pro的最新版去解析，Pro版去正常使用？两者的数据格式兼容吗？

实际上我估计不是这个问题，因为这在第一次同步的时候就出错，我的用法可能有点不一样，因为我微信数据小一个T（大概有10年的数据了），不想浪费两遍存储空间，所以我是直接把整个微信的working dir放到了NAS上，PC上通过SMB映射后用的，然后docker的对应目录用的mount --bind -o ro把FileStorage只读映射过去，数据库用rsync同步过去，不知道是否有影响。

具体的说：
微信在NAS上的位置：
/volume1/homes/{用户名}/WeChatPC/WeChat\ Files/{微信ID}/

Docker的映射：
/volume1/docker/cloudbak-pro:/app/data:rw

目录映射脚本（NAS开机自启动防止意外重启丢失映射）：

mount --bind -o ro /volume1/homes/{用户名}/WeChatPC/WeChat\ Files/{微信ID}/FileStorage /volume1/dock
er/cloudbak-pro/sessions/1/{微信ID}/FileStorage

rsync定时脚本（每天00:00同步数据库文件，但我电脑24小时不关机，所以有大概率同步文件时微信正在运行状态）：

rsync -au /volume1/homes/{用户名}/WeChatPC/WeChat\ Files/{微信ID} /volume1/docker/cloudbak-pro/sessions/
1/ --exclude={'/{微信ID}/Applet/','/{微信ID}/Recovery/','/{微信ID}/ResUpdateV2/','/{微信ID}/Backup/','/{微信ID}/BackupFiles/','/{微信ID}/FileStorage/','*.thumbs.db','*.db-shm','*.db-wal'}

所以，对于cloudbak-pro应该能看到的是最后一次commit的数据库副本（可读写）以及FileStorage文件夹的只读映射。不知道是否因为这个原因会导致bug？我大概翻了一下源文件，似乎没找到对FileStorage的写需求（可能有，我没细看），但这里还没涉及到图片和文件等的操作，就已经报错了，不知道问题在哪里。

likeflyme

Tide Gu
错误原因只跟读取解析出来的数据库文件有关，由于sqlite数据库为文件，有可能在某一个时刻没有正确关闭连接导致文件写入失败造成数据库文件格式错误就有可能遇到这个问题，pro版的beta版本有全量解析功能可以处理这个问题，最近的版本为 2.0.6-beta。
微信3存储的数据库文件目录名为 Msg目录，从你的错误来看，是读取其中一个消息库文件有错误，这个库文件在 Msg/Multi/decoded_MSGX.db（X为数字），只要删除掉这个文件重新解析一次就好了。

Tide Gu

likeflyme 我尝试了升级更新，现在的状态是在刷新解析任务列表（http://IP:9527/api/task/log?task_id=x）时经常报这个错误：
{"detail":"Internal server error, (sqlite3.OperationalError) database is locked\n[SQL: SELECT sys_task.id AS sys_task_id, sys_task.name AS sys_task_name, sys_task.state AS sys_task_state, sys_task.detail AS sys_task_detail, sys_task.create_time AS sys_task_create_time, sys_task.update_time AS sys_task_update_time, sys_task.owner_id AS sys_task_owner_id \nFROM sys_task \nWHERE sys_task.id = ?]\n[parameters: (3,)]\n(Background on this error at: https://sqlalche.me/e/20/e3q8)"}

怀疑和NAS的硬盘负载和Msg文件夹大小有关，我的Msg文件夹大概有17G，的确很大，Msg/Multi/下有最大900多M的文件，以及大量200M以上的文件，这个作为个bug report建议您后期对大文件读写时的locking或者committing机制做一下优化吧。

至于rsync，我新版又改了一下，把定时脚本设定为只同步Msg文件夹了，这样似乎更稳定一些，尤其是FileStorage，直接靠只读mount，其它文件夹我搜了下源码似乎都没用到，所以现在/app/data/sessions/1/{微信ID}下只有一个rsync过来的Msg文件夹和一个只读mount过来的FileStorage文件夹，这样应该足够项目正常运行了吧？新的rsync脚本如下：

rsync -au /volume1/homes/{用户名}/WeChatPC/WeChat\ Files/{微信ID}/Msg /volume1/docker/cloudbak-pro/sessions/
1/{微信ID}/ --exclude={'*.thumbs.db','*.db-shm','*.db-wal'}

如果有效，也可以给其它使用者参考，另外，似乎这个exclude可以去掉*.thumbs.db，因为Msg文件夹下理论上不会有这个文件，本身是给FileStorage用的。当然，保留它也没啥问题。还有.mmkv.crc和.mmkv文件似乎也可以忽略掉，没在源码里找到相关解析内容，如果这些文件有用，也请您明示，谢谢！

现在大部分功能都能正常运行，包括文件下载和语音消息都能播放，但是发现一个问题，就是图片的解析是写入原文件夹的，不像语音解析到decoded_Media，这在我的使用场景中因为FileStorage是只读加载的，所以日志里会疯狂报错且看不到图片，能否提一个Feature Request，把图片也解析到单独的decoded文件夹或者加一个选项？我相信也会有一些用户有类似的需求，整个微信文件夹太大了，多复制或者rsync一遍浪费空间不说，主要是浪费时间。Msg文件夹好在文件数量不多，浪费空间也就罢了，但FileStorage零碎文件太多了，又不敢直接读写映射给cloudbak，怕写进去的解析文件在微信端引起bug，所以如果能参考decoded_Media给解析到其它文件夹就太棒了！当然，如果Msg文件夹也能解析到其它文件夹，能把rsync都省了，那能省更多的事儿……

likeflyme

Tide Gu

关于刷新task报错，这个我关注一下；
关于需要挂载的目录，确实只需要 FileStorage 和 Msg，MMKV目录也没有用到，可以排除；
关于解析数据单独存储，是的，这个可以优化，等更新。

Tide Gu

likeflyme 非常感谢大佬接受这个Feature Request！期待新版！我暂时就先用这个对我来说无图片的版本啦~
还有一个建议就是把gh和@chatroom在列表里分开，我这边关注到有个人公众号跟他个人微信号头像相同的，一开始发现列表里有两个一样头像的还以为是bug，后来仔细看了才知道一个是公众号一个是个人聊天窗口。如果主列表做二级列表麻烦的话其实也可以把gh单独放在导航栏里的，毕竟需要找公众号的需求还是少一点的。

likeflyme

Tide Gu 这是按照微信3的微信聊天界面写的，为了兼容微信4以后会改成微信4这种分开的方式。

Tide Gu

likeflyme 还没升级微信4，就怕聊天记录出问题…尤其是我这几百G的聊天记录，光Msg文件就小20G的，又放在NAS上的，一旦出问题能急死个人。
但是话说回来，如果升级微信4，是需要重新创建任务，还是无感使用就行？

likeflyme

Tide Gu
如果要升级微信4，需要创建一个新的会话与微信3的会话区分开。
不过微信4的支持目前很弱，只能解析文字，视频，图片也只能解析缩略图并且配置比较麻烦。

Tide Gu

likeflyme 谢谢，除非被微信强行升级了，否则暂时不打算升。就等您解析数据单独存储的更新啦_{虽然可能只是替换几行代码的事儿，但估计您还得考虑迁移和兼容性的问题，这就复杂很多了}我静候佳音~_！

Tide Gu

likeflyme 我看到现在最新的是2.0.3，然后我现在用的是2.0.6-beta，有点看不明白我应该“升级”到2.0.3还是保持2.0.6-beta，按时间看2.0.3更新，按编号看2.0.6更新，有点迷。。。

likeflyme

Tide Gu 升到2.0.3就对了