[Bug] Deterministic .imprint_tmp filenames can cause race conditions during concurrent dedupe/restore operations

[dheeraj12347]

Description

Summary

The temporary files used during deduplication, restoration, and vault operations are created using a deterministic naming pattern:

temp.set_extension("imprint_tmp");

This generates predictable temporary file names such as:

file.txt      -> file.imprint_tmp
archive.zip   -> archive.imprint_tmp
photo.jpg     -> photo.imprint_tmp

The same pattern is currently used in both src/dedupe.rs and src/vault.rs.

What is the issue?

Because the temporary filename is always derived from the target path, multiple bdstorage processes operating on the same file or dataset can end up using the exact same temporary path.

For example:

bdstorage dedupe /data

while another terminal runs:

bdstorage restore /data

or

bdstorage dedupe /data

before the first operation completes.

In such situations, both processes may attempt to create, rename, or delete the same .imprint_tmp file.

Why is this a problem?

This can lead to race conditions where:

• One process removes a temporary file currently being used by another process.
• Rename operations interfere with each other.
• Dedupe or restore operations fail unexpectedly.
• Recovery behavior becomes unpredictable during concurrent execution.
• Future parallelization efforts may become unsafe due to temporary-file collisions.

Since bdstorage is designed as a storage-management and data-safety tool, temporary-file collisions could impact reliability during long-running or concurrent operations.

Affected Locations

src/dedupe.rs

let mut temp = target.to_path_buf();
temp.set_extension("imprint_tmp");

src/vault.rs

let mut temp = dest.to_path_buf();
temp.set_extension("imprint_tmp");

Expected Behavior

Temporary files should be uniquely generated per operation/process to avoid collisions.

Possible approaches include:

• tempfile::NamedTempFile
• PID-based suffixes
• UUID/randomized temporary filenames

Example:

file.imprint_tmp_12345
file.imprint_tmp_f83a7c

instead of:

file.imprint_tmp

Why it is important to fix

bdstorage emphasizes reliability, safe recovery, and atomic filesystem operations. Ensuring that temporary files are uniquely generated would:

• Improve robustness during concurrent execution.
• Prevent accidental interference between running processes.
• Reduce the risk of failed dedupe/restore operations.
• Make future parallel or daemon-based workflows safer.
• Strengthen overall filesystem safety guarantees.

Additional Context

I could not find any explicit process-level locking mechanism protecting these temporary files. If concurrent execution is intentionally unsupported, it may be beneficial to either enforce this through a lock mechanism or document the limitation clearly.

---

I am a GSSoC 2026 contributor and would like to work on this issue. If the maintainers agree that this is a valid concern, please assign it to me and I will submit a PR with the necessary changes and tests.