基于Rust notify crate的文件监视器：如何判断文件是否仍被其他进程写入？

这个问题我之前做Rust文件同步工具的时候也踩过坑，太懂这种刚看到文件创建就触发动作，结果打开文件发现内容不完整的挫败感了！结合我自己的实践和Rust社区里的方案，给你几个针对性的解决思路，尤其是针对你提到的Firefox下载场景：

1. 尝试独占式打开/加锁（最直接的跨平台方案） #

核心思路是：如果文件还被其他进程写入，那么我们大概率无法以独占模式打开它，或者无法获取它的排他锁。Rust的fs2 crate封装了跨平台的文件锁操作，用这个来判断非常方便。

具体实现逻辑：尝试以写模式打开目标文件，并请求排他锁——如果成功，说明当前没有其他进程在写入这个文件；如果失败，说明文件正被占用。

示例代码：

use fs2::FileExt;
use std::fs::OpenOptions;
use std::path::Path;

fn is_file_ready(path: &Path) -> bool {
    // 先检查文件是否存在
    if !path.exists() {
        return false;
    }

    match OpenOptions::new().write(true).open(path) {
        Ok(mut file) => {
            // 尝试获取排他锁，非阻塞模式
            match file.try_lock_exclusive() {
                Ok(_) => {
                    // 成功获取锁，说明文件可安全处理
                    // 注意：这里锁会在file被drop时自动释放
                    true
                }
                Err(_) => {
                    // 无法获取锁，文件大概率正在被写入
                    false
                }
            }
        }
        Err(_) => {
            // 无法以写模式打开（比如权限问题，或者文件被其他进程独占打开）
            false
        }
    }
}

2. 监控文件大小的稳定状态（应对非锁场景） #

有些程序写入文件时不会用文件锁，这时候可以通过检查文件大小是否在一段时间内保持不变来判断是否写完——毕竟文件还在写入时，大小会持续变化。

你可以结合notify的防抖（debounce）机制，再加上一轮轮询检查：比如收到文件修改事件后，先等500ms，然后每隔200ms检查一次文件大小，连续2次大小相同就认为文件写完了。

示例代码（用tokio异步实现，同步场景可以换成std::thread::sleep）：

use std::fs::metadata;
use std::path::Path;
use tokio::time::{sleep, Duration};

async fn wait_for_file_stable(path: &Path, timeout: Duration, check_interval: Duration) -> bool {
    let start = std::time::Instant::now();
    let mut last_size: Option<u64> = None;
    let mut stable_count = 0;

    while start.elapsed() < timeout {
        match metadata(path) {
            Ok(meta) => {
                let current_size = meta.len();
                if let Some(prev) = last_size {
                    if current_size == prev {
                        stable_count += 1;
                        // 连续2次大小相同，认为稳定
                        if stable_count >= 2 {
                            return true;
                        }
                    } else {
                        stable_count = 0;
                    }
                }
                last_size = Some(current_size);
            }
            Err(_) => {
                // 文件被删除了，直接返回
                return false;
            }
        }

        sleep(check_interval).await;
    }

    // 超时仍未稳定，放弃
    false
}

3. 结合临时文件的命名规则（针对Firefox这类场景） #

你提到Firefox会生成.part后缀的临时文件，其实很多程序都会遵循“先写临时文件，再原子重命名为最终文件”的规范——重命名操作在大多数文件系统上是原子的，也就是说，当你监控到重命名事件到最终文件名时，文件已经完全写入了。

针对你的场景，你可以：

• 先忽略所有.part后缀的文件事件
• 对于.iso文件，优先检查是否是通过重命名生成的（notify的EventKind::Modify(ModifyKind::Name(Rename))事件），如果是，直接处理
• 如果是普通的Create/Modify事件，再用上面的1或2方法验证文件是否写完

不过要注意：Firefox的下载逻辑可能有些特殊（比如直接写入最终文件+生成.part进度文件），所以这个方法可能需要结合前两种一起用。

4. 组合方案（推荐） #

针对你给出的事件序列，我建议用这样的流程来处理：

1. 收到文件事件后，先过滤掉临时文件（比如.part）
2. 对于目标文件（.iso），先调用is_file_ready检查是否能独占打开
3. 如果检查通过，直接执行你的处理逻辑
4. 如果检查失败，就启动wait_for_file_stable等待大小稳定，稳定后再检查一次is_file_ready，通过后再处理
5. 如果超时还没稳定，就放弃这次事件（避免无限等待）

一些额外提醒 #

• 跨平台注意：Windows和Unix的文件锁行为略有差异，fs2 crate已经帮我们做了封装，但还是要注意，有些恶意/不规范的程序可能会绕过锁机制
• 防抖配合：notify的notify-debouncer-full已经能帮你合并连续的Modify事件，但不要依赖它来判断文件是否写完——它只能减少事件数量，不能保证文件状态
• 资源释放：用fs2加锁后，记得让File对象正常drop，锁会自动释放，不要手动持有太久

内容来源于stack exchange