Skip to content

[Bug] Scanner silently excludes legitimate user files ending with .imprint_tmp #74

Description

@dheeraj12347

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions