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 Text Build Linux版

Sublime Text Linux x86-64 deb 安装包。官方也提供 rpm、tar.xz 和软件源安装方式。

下载

• 在 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$homeproject 访问，避免 /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 就可能持续静默失败——它不报错，也不写日志，只让保存变成“按了等于没按”。