Description
Summary
The scanner currently skips any file whose filename ends with .imprint_tmp:
if entry
.file_name()
.to_string_lossy()
.ends_with(".imprint_tmp")
{
continue;
}
This logic is intended to avoid processing temporary files created by bdstorage during dedupe and restore operations.
What is the issue?
The filter is based solely on the filename suffix and does not verify whether the file is actually a temporary file created by bdstorage.
As a result, legitimate user files such as:
backup.imprint_tmp
report.imprint_tmp
dataset.imprint_tmp
are silently excluded from scanning.
These files are never:
- Indexed
- Hashed
- Considered for deduplication
- Included in vault statistics
Why is this a problem?
Users may legitimately store files ending with .imprint_tmp and expect them to participate in deduplication like any other file.
The current behavior creates a hidden exclusion rule that can lead to:
- Missed deduplication opportunities
- Inaccurate scan results
- Confusing behavior when files appear to be ignored
- Reduced trust in scan completeness
Expected Behavior
Only temporary files actively created and managed by bdstorage should be excluded.
Possible approaches:
- Track temporary files using dedicated metadata instead of filename matching.
- Store temporary files in a dedicated internal location.
- Use uniquely generated temporary filenames and validate ownership before skipping.
- Restrict exclusion to known active temporary files rather than all files ending with
.imprint_tmp.
Affected Location
src/scanner.rs
if entry
.file_name()
.to_string_lossy()
.ends_with(".imprint_tmp")
{
continue;
}
Why it is important to fix
bdstorage aims to provide reliable and complete filesystem deduplication. Silently excluding user files based solely on a filename suffix can cause legitimate files to be omitted from deduplication workflows and produce incomplete scan results.
I am a GSSoC 2026 contributor and would like to work on this issue. If this behavior is considered unintended, please assign it to me and I will submit a PR with the required changes and tests.
Description
Summary
The scanner currently skips any file whose filename ends with
.imprint_tmp:This logic is intended to avoid processing temporary files created by bdstorage during dedupe and restore operations.
What is the issue?
The filter is based solely on the filename suffix and does not verify whether the file is actually a temporary file created by bdstorage.
As a result, legitimate user files such as:
are silently excluded from scanning.
These files are never:
Why is this a problem?
Users may legitimately store files ending with
.imprint_tmpand expect them to participate in deduplication like any other file.The current behavior creates a hidden exclusion rule that can lead to:
Expected Behavior
Only temporary files actively created and managed by bdstorage should be excluded.
Possible approaches:
.imprint_tmp.Affected Location
src/scanner.rsWhy it is important to fix
bdstorage aims to provide reliable and complete filesystem deduplication. Silently excluding user files based solely on a filename suffix can cause legitimate files to be omitted from deduplication workflows and produce incomplete scan results.
I am a GSSoC 2026 contributor and would like to work on this issue. If this behavior is considered unintended, please assign it to me and I will submit a PR with the required changes and tests.