Skip to content

Hide zero-byte images until locally available - #1644

Open
reville wants to merge 1 commit into
CyberTimon:mainfrom
reville:codex/hide-unavailable-placeholders
Open

Hide zero-byte images until locally available#1644
reville wants to merge 1 commit into
CyberTimon:mainfrom
reville:codex/hide-unavailable-placeholders

Conversation

@reville

@reville reville commented Aug 30, 2026

Copy link
Copy Markdown

Description

Hide zero-byte supported images from RapidRAW's library until their contents are locally available.

Zero-byte image files cannot be decoded and commonly represent cloud-sync placeholders that have been listed locally before their provider downloads the actual bytes. Showing them produces broken thumbnails and load errors even though the remote original may be fine.

The check is provider-agnostic and cross-platform. RapidRAW reads fresh metadata on each scan, so an image automatically becomes discoverable on the next refresh after Dropbox, iCloud, or another provider hydrates it.

This is intentionally separate from #1643, but complements it: zero-byte placeholders are filtered consistently for every supported image format.

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Performance improvement
  • Code refactoring
  • Documentation update
  • UI/UX improvement
  • Build/CI or Dependency update

Changes Made

  • Add a shared is_nonempty_supported_image_file discovery predicate while preserving extension-only checks for pickers and file operations.
  • Exclude zero-byte images from normal and recursive folder views, album views, folder image counts, and background indexing.
  • Re-evaluate file size on every scan so hydrated images reappear without provider-specific state or persistent exclusion.
  • Add tests proving that an empty supported image is hidden, becomes discoverable after content is written, and that missing or unsupported paths remain excluded.

Screenshots/Videos

Not applicable; the intended result is that unavailable zero-byte tiles no longer render.

Testing

  • These changes were tested locally by a human and confirmed to work.
  • Automated tests cover the new discovery behavior.

Test Configuration:

  • OS: macOS
  • Hardware: Apple Silicon

Checks:

  • cargo test --manifest-path src-tauri/Cargo.toml --lib — 2 passed
  • cargo check --manifest-path src-tauri/Cargo.toml
  • cargo fmt --manifest-path src-tauri/Cargo.toml -- --check
  • git diff --check
  • cargo clippy --all-targets --all-features -- -D warnings -A clippy::collapsible_if

The repository's unmodified src-tauri/src/exif_processing.rs currently triggers the pre-existing collapsible_if warning under the exact strict Clippy command. With that unrelated baseline lint allowed, all targets and features pass Clippy with -D warnings.

Checklist

  • My code follows the project's code style
  • I haven't added unnecessary AI-generated code comments
  • My changes generate no new warnings or errors

Additional Notes

This deliberately checks for zero length rather than Dropbox- or iCloud-specific attributes. A zero-byte file cannot be a decodable image regardless of provider, while non-empty cloud entries keep RapidRAW's existing placeholder behavior.

AI Disclaimer

  • This PR is created by an AI agent
  • This PR is mostly AI-generated but edited/merged together by a human
  • This PR was handwritten with AI assistance (spell check, logic suggestions, error resolving)
  • This PR contains only blood, sweat, and coffee (AI-free)

@reville
reville requested a review from CyberTimon as a code owner August 30, 2026 19:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant