Snakemake 本身不直接“锁定目录”，但将目录声明为 rule 的 output（使用 directory()）可间接实现排他性访问；需注意该操作会触发目录及其全部内容在执行前被清空，存在数据丢失风险。
snakemake 本身不直接“锁定目录”，但将目录声明为 rule 的 `output`（使用 `directory()`）可间接实现排他性访问；需注意该操作会触发目录及其全部内容在执行前被清空，存在数据丢失风险。
在 Snakemake 工作流中，资源并发安全是分布式执行（如 --cores, --cluster）下的关键问题。虽然 Snakemake 官方明确说明其通过文件级锁（file-based locking）保障输出文件的独占写入（见 FAQ），但它并不原生支持对任意目录的递归锁或原子性目录锁。不过，可通过将目标目录显式声明为 rule 的 output，利用 Snakemake 的输出依赖调度机制，实现逻辑上的“目录级互斥”——即：只要两个 rule 将同一目录列为 output，Snakemake 就不会并发执行它们（因其视该目录为共享输出资源，需串行化调度）。
✅ 正确用法：directory() 实现调度层互斥
rule process_in_shared_dir:
output:
directory("results/shared_cache")
shell:
"mkdir -p {output} && "
"some_tool --input data.txt --output-dir {output}"此时，若另一 rule 同样声明 output: directory("results/shared_cache")，Snakemake 会将其视为冲突输出，强制串行执行（即使实际写入的子文件不同）。这是目前最可靠、且被官方文档支持的目录级协调方式。
⚠️ 关键注意事项（务必牢记）
-
目录会被预先清空：Snakemake 在 job 执行前，会递归删除 directory() 声明的整个目录及其所有内容（参见 Directories as outputs）。这意味着：
- 若目录中存在需保留的中间文件或跨 rule 共享数据，此方式不可用；
- 务必确保该目录仅用于当前 rule 的专属输出，或在 rule 中主动重建所需结构。
- 非递归锁，也非运行时锁：directory() 不产生操作系统级文件锁，也不监控目录内文件变更；它仅影响 Snakemake 的调度决策。若外部进程（非 Snakemake 管理）同时读写该目录，仍需额外同步机制（如 flock）。
- 无法替代细粒度文件锁：若多个 rule 写入同一目录下不同子路径（如 out/a/ 和 out/b/），且不共享 output 声明，则 Snakemake 不会感知冲突——此时应改用更精确的输出文件声明，或引入外部锁工具。
✅ 替代方案（当 directory() 不适用时）
若需保留目录内容或实现更灵活的并发控制，推荐组合使用：
import os
import fcntl
rule safe_write_to_shared_dir:
output:
"results/shared_cache/.lock_acquired" # 虚拟标记文件
run:
lock_path = "results/shared_cache/.snakemake_lock"
with open(lock_path, "w") as f:
fcntl.flock(f.fileno(), fcntl.LOCK_EX)
try:
# 在此处安全执行所有读写操作
shell("some_tool --input data.txt --output-dir results/shared_cache")
finally:
fcntl.flock(f.fileno(), fcntl.LOCK_UN)总结：directory() 是 Snakemake 提供的、语义清晰的目录级互斥手段，适用于“目录完全由单个 rule 独占管理”的场景；但因其附带强制清理副作用，使用前必须评估数据生命周期。对于复杂共享目录，建议优先细化输出文件粒度，或结合系统级锁（如 fcntl）实现更健壮的并发安全。
