Win10下构建ESP32 Rust项目esp-idf-sys报访问被拒(os error 5)错误

1. 管理员身份运行仍触发Access is denied. (os error 5)的原因 #

该错误绝大多数出现在Windows平台，本质不是权限不足，而是目标文件被其他进程加了独占锁，被锁定的资源是esp-idf-sys构建时自动拉取存放在缓存路径（通常是用户目录下的.espressif文件夹，或是项目target目录下的.embuild缓存目录）的ESP-IDF源码、临时编译产物文件。
常见触发原因如下：

• 杀毒软件实时扫描占用：Windows Defender或第三方杀毒软件会对构建过程中cmake、ninja频繁生成、修改、删除的临时文件做实时扫描，扫描期间会给文件加独占锁，管理员权限也无法绕过这类锁。
• 残留进程或索引服务占用：之前构建失败残留的cmake、ninja、cargo后台进程未退出，会持续持有缓存文件的句柄；VS Code、CLion等IDE打开项目时的代码索引服务，也可能自动扫描新增源码文件并加锁。
• 特殊路径问题：如果缓存目录或项目路径包含非ASCII字符、空格，或是目录被设置了强制只读属性，也可能触发该错误，但管理员运行仍报错的场景下该原因概率极低。

常规排查顺序：

• 将~/.espressif目录、项目target目录加入杀毒软件排除列表，临时关闭实时防护后测试构建。
• 打开任务管理器，结束所有名称带cmake、ninja、xtensa-esp32-elf、cargo的残留进程后重新构建。
• 若在WSL环境下构建，不要放在/mnt/开头的Windows挂载分区下执行，跨文件系统权限映射也会触发该类错误。

2. fatal: No names found, cannot describe anything.提示的含义与产生原因 #

该提示是Git抛出的非阻断性警告，和最终构建失败没有直接关联。

• 具体含义：git describe指令的作用是基于当前仓库的标签，生成可识别的版本号字符串；当指令执行的目标Git仓库没有任何标签，或是当前提交没有可达的标签引用时，Git就会返回该提示。
• 产生原因：esp-idf-sys拉取对应版本ESP-IDF源码时默认使用浅克隆模式，仅拉取对应提交的代码文件，不会拉取全量提交历史和标签数据。构建脚本调用git describe尝试获取ESP-IDF版本字符串时，本地浅克隆仓库没有对应标签数据就会触发该提示。切换到v4.3.2版本时未出现该提示，仅对应该版本的构建流程未触发该条Git指令，或是浅克隆时刚好拉取到了对应标签，和访问被拒错误无关。

内容的提问来源于stack exchange，提问作者Ababwa