你在文件管理器里把媒体库的目录改了个更顺眼的名字，本以为是件无关紧要的小事。回到媒体库软件里一看——一个片子都扫不到了，界面空空如也。你打开文件夹，文件明明都还在，一个没少。明明只是改了个名，怎么像"文件全丢了"？
现象
- 媒体库的目录被重命名（比如从
/data/media改成/data/library）； - 打开媒体库，条目不显示或全部失效，看起来像"文件丢了"；
- 但用文件管理器去看，文件全部完好无损，就在新名字的目录里。
这个"软件说没有、文件系统说都在"的矛盾，就是线索。
根因
根因是：媒体库把扫描目录的路径持久化存进了数据库（比如 SQLite），目录一改名，数据库里存的还是旧路径。
媒体库软件的工作方式通常是：
- 你告诉它"去某个目录扫描媒体文件"；
- 它扫描后，把每一条记录连同文件的完整路径一起写进数据库，用于后续快速展示、去重、识别；
- 展示时，它按数据库里存的旧路径去找文件。
当你把目录改名后，数据库里记的仍然是 /data/media/xxx.mkv，而磁盘上这个路径已经不存在了——真实文件现在在 /data/library/xxx.mkv。软件拿着旧路径去找，找不到，于是把所有条目都当成"文件已删除"处理，界面就空了。
换句话说："改名"在你的操作里是移动，在软件的视角里是"旧文件消失、新文件出现"。 而它没有被通知"新文件"需要重新入库，所以旧记录全部悬空。
这就是为什么"文件还在"和"库里空了"能同时成立——数据库记的是路径，不是文件本身。 路径一失效，引用就断了。
解决
最直接的办法：改完名之后，在界面里重建媒体库。
常规流程是：
- 进入媒体库软件的"库管理/媒体库设置"；
- 把库的扫描目录指向新的路径（或者在库设置里直接改路径）；
- 触发一次重新扫描或重建库，让它按新路径重新索引。
不同软件的菜单叫法不同，但核心动作就一个：让库知道路径变了，并重新建立索引。
如果软件允许直接改数据库，理论上也可以把旧路径批量替换成新路径（比如把 path 列里的旧前缀 UPDATE 成新前缀），但不推荐：一来表结构、关联表、哈希缓存可能不止一处存路径，改漏一处又会出新的不一致；二来官方通常提供了"重建"入口，用软件自己的机制更稳妥。真要在数据库层动，先备份整个库文件再操作：
cp library.db library.db.bak
改完后再校验：新路径下的条目能正常展示、能播放、封面正常。别只看"条数对上了"就收工。
延伸与预防
这条坑的通用教训是：把文件系统路径持久化进数据库，就等于把"改名"变成了"数据损坏"。
路径是外部世界的标识，一旦写死进数据库并长期依赖，任何外部的重命名、移动、挂载点变化，都会让它变成悬空引用。几条可复用的做法：
- 优先用"稳定标识"而非路径。成熟的媒体库会用文件的内容哈希、inode、或 UUID 来标识条目，路径只是"当前位置"，变更时自动跟随。选型或设计时优先这类方案。
- 把"改名/移动"当作一等操作。如果必须存路径，就在应用里提供"迁移/重定位"入口，让路径变更走正规流程，而不是让用户去操作系统文件管理器。
- 扩容、搬盘、改挂载点时提前规划。这些操作都会改路径，事前想好库要怎么重新指向，能省下事后一场虚惊。
一句话：只要一个系统"用路径代表文件"，那它就必须把路径会变这件事，当作常态来设计。