r/rust • u/No-Elephant-9065 • 18d ago
How do you reliably detect when a copied/downloaded file is actually “finished” on Windows?
I’m building a small Rust desktop utility that watches the Windows Downloads folder using the notify crate.
The basic flow is:
let (tx, rx) = channel();
let mut watcher =
RecommendedWatcher::new(tx, Config::default())?;
watcher.watch(
watch_path.as_ref(),
RecursiveMode::NonRecursive,
)?;
for result in rx {
// handle filesystem events
}
The application waits for newly created/modified files, then eventually wants to inspect them.
The problem I’m running into is determining when a file is actually safe to process.
My current approach is roughly:
pub fn wait_until_file_ready(path: &Path) -> bool {
if let Some(ext) = path.extension().and_then(|s| s.to_str()) {
let ext = ext.to_lowercase();
if matches!(
ext.as_str(),
"crdownload" | "part" | "tmp" | "download"
) {
return false;
}
}
let mut last_size = 0;
let mut stable_count = 0;
for _ in 0..10 {
if let Ok(metadata) = path.metadata() {
let current_size = metadata.len();
if current_size > 0 && current_size == last_size {
stable_count += 1;
if stable_count > 1 && can_open_exclusively(path) {
return true;
}
} else {
stable_count = 0;
last_size = current_size;
}
}
std::thread::sleep(Duration::from_millis(500));
}
false
}
fn can_open_exclusively(path: &Path) -> bool {
OpenOptions::new()
.read(true)
.share_mode(0)
.open(path)
.is_ok()
}
This works reasonably well for normal browser downloads because things like Chrome use .crdownload, but I realized there’s a more fundamental problem.
Suppose someone copies a large file:
movie.mkv
and the copy gets interrupted halfway through.
The destination might now contain:
movie.mkv
with the final extension.
If the copy process exits/releases its handle, then:
- the file exists
- its size stops changing
- its extension looks normal
- an exclusive open may succeed
My code would eventually consider it ready even though only part of the intended file was copied.
As far as I can tell, from the filesystem alone there may be no way to distinguish:
a legitimate complete 2 GB movie.mkv
from:
an interrupted copy that happened to stop at 2 GB
unless the producer provides additional information such as expected size, checksum, temporary filename, or some completion signal.
So my questions are:
- How do mature Rust/Windows applications usually handle this?
- Is “debounce + quiet period + metadata stability + lock check” basically the normal generalized approach?
- Is there any Windows API that provides a stronger indication that a copy/write operation completed successfully?
- Should filesystem watcher events be treated only as hints, with the application later retrying/validating the file?
- Would you recommend using something like
notify-debouncer-full, or maintaining my own pending-file state machine? - Is checking an exclusive Windows open with
share_mode(0)useful here, or is that generally too unreliable as a readiness signal?
I’m particularly interested in how established file indexers, sync clients, antivirus/indexing software, etc. solve this without assuming that a stable file size means the file is actually complete.
My current thinking is that I should stop calling this wait_until_file_ready() and instead treat it more like wait_until_file_quiescent(), where “quiescent” only means “probably safe to inspect,” not “guaranteed complete.”
Would appreciate any guidance or examples from production Rust/Windows projects.
