Sublime Text数据备份卡住实为atomic_save被静默拦截：在/mnt/c/、OneDrive、NAS等路径下，rename操作被系统拒绝却不报错，导致界面卡死、状态栏仍显示“modified”。
Sublime Text 数据备份卡住，根本不是编辑器在“备份”，而是它在尝试原子保存（atomic_save）时被底层文件系统静默拦截——rename 操作失败但不报错，界面卡死、状态栏仍显示 “modified”，磁盘时间戳不变。这不是崩溃，是哑巴式写入失败。
为什么 backup 卡住其实是 atomic_save 被拦截
Sublime Text 的“保存”本质是：先写临时文件，再 rename 覆盖原文件。这个 rename 在以下路径会被系统或中间层直接拒绝，且不返回错误码：
-
/mnt/c/（WSL2 访问 Windows 磁盘）：Windows 驱动禁止跨子系统重命名 - OneDrive / Dropbox “按需同步”目录：文件未完全落地，客户端拦截
rename - SMB/NAS 挂载卷：固件不支持原子替换，或权限模型不兼容
- VeraCrypt 加密容器、只读 ext4 分区：内核直接拒写，Sublime 不弹窗也不记日志
此时你看到的“卡住”，是 Sublime 在等待一个永远不会完成的系统调用。
怎么快速验证是不是 atomic_save 导致卡住
别猜路径，用终端复现 Sublime 的保存行为：
- 在 Sublime 控制台（
Ctrl + `）中执行：view.window().active_view().file_name()—— 如果这步卡住或报Permission denied，就是硬盘/文件系统层锁死 - 对比测试：
cp your_file.txt ~/Desktop/test_copy.txt—— 若能成功，说明问题锁定在原路径 - 检查当前文件是否在 OneDrive 按需同步中：右键文件夹 → “始终在此设备上保留”
绕过卡住的实操方案（不修权限也能用）
禁用 atomic_save 是最快生效的调试手段，但它只是绕过 rename，不解决根本权限问题：
- 打开
Preferences → Settings，在右侧用户设置中添加："atomic_save": false - 保存后立即生效，Sublime 改为直接覆写原文件（风险：断电可能丢数据）
- 更安全的长期做法：
– 把项目移到~/Documents（macOS/Linux）或%USERPROFILE%Documents（Windows）等本地可写路径
– WSL2 用户改用\wsl$<distro>home<user>project</user></distro>访问，避免/mnt/c/
– OneDrive 用户右键文件夹 → “始终在此设备上保留”
进程异常卡死后怎么清理缓存才有效
卡住后若强行关掉 Sublime，Cache、Index、Local 三处缓存极可能被锁住或状态不一致，导致下次启动卡在 “Initializing”：
- 务必先彻底杀掉所有进程：
– Windows：任务管理器中结束所有sublime_text.exe和subl.exe
– macOS：活动监视器中搜索 “Sublime Text”，强制退出全部实例
– Linux：pkill -f "sublime_text"或pkill -f "subl" - 再删除三处路径（缺一不可）：
– Windows：%APPDATA%Sublime TextCache、%LOCALAPPDATA%Sublime TextCache、%APPDATA%Sublime TextLocalIndex
– macOS：~/Library/Application Support/Sublime Text/Cache、~/Library/Caches/Sublime Text、~/Library/Application Support/Sublime Text/Local/Index
– Linux：~/.config/sublime-text/Cache、~/.cache/sublime-text、~/.config/sublime-text/Local/Index - 删完首次启动稍慢是正常的——它在重建干净缓存，但不会再卡在初始化阶段
真正容易被忽略的是：即使你修复了权限，只要路径仍在受控文件系统上，atomic_save: true 就可能持续静默失败——它不报错，也不写日志，只让保存变成“按了等于没按”。
