Is there loss of metadata during backup?

Development
, ,
1

Gramps recognizes that Media objects may have metadata sidecars. But does it gather up sidecars during exports? Or is that a dataloss during export?

2

And there can be multiple sidecars for Media object.

Besides the embedded metadata (that naturally travels within the media object), Media objects might have one (or more) sidecar that matches the media object filename but with a different extension… such as the .xmp file extension.

But there can also be indexed sidecars that are indices of files in the folder. Like the hidden Picasa .picasa.xmp .picasa.ini file in XMP format. That has the complication that the Gramps export might not have all the indexed files attached as Media objects.

Filtered exports increase the likelihood that some of the sidecar listings won’t be valid when the backup file is restored.

3

Is that file something that Gramps creates? The only hidden .picasa files I’ve ever seen are all called .picasa.ini (one per folder).

4

You’re right. Working from memory at my age is fraught with dangers.

5

asked Gemini to assess the Gramps approach, suggesting comparison of its Media data stucture to an amalgamated metadata database

Yes, conceptually, Gramps operates very much like an internalized, highly structured “amalgamated metadata sidecar,” though with a major architectural twist: instead of sitting beside your files as individual companion files (like .xmp or .picasa.ini), Gramps pulls all that relational metadata into a centralized database (SQLite or BSDDB) while leaving your raw media files completely untouched on your hard drive.

Comparing how Gramps handles media management to traditional sidecar systems highlights several key similarities and differences:

1. How Gramps Parallels a Sidecar System

  • Decoupling Metadata from the Master File: Just like a sidecar file prevents you from having to bake edits, tags, or copyright data directly into a raw photo or document, Gramps keeps your master image, PDF, or audio files pure and unmodified.
  • The “MetaMedia” Layer: Gramps creates an internal “Media Object” record for every file you link. This record acts as a virtual container holding titles, dates, author info, notes, source citations, and bounding-box crop/region-of-interest markers (such as pointing out a specific person’s face in a group photo). This is conceptually identical to the data stored inside a .picasa.ini or .xmp file.
  • Path and Checksum Tracking: Traditional sidecars rely on matching filenames to stay tethered to their assets. Gramps maintains absolute or relative file paths coupled with digital checksums. This allows Gramps to track your media even if you move or rename the underlying files—acting like a smart, self-healing sidecar index.

2. Where Gramps Differs from Traditional Sidecars

While standard sidecars are file-based and decentralized (one .xmp per photo, or one .picasa.ini per folder), Gramps treats media metadata as part of an interconnected relational graph:

  • Many-to-Many Mapping: A sidecar file belongs strictly to one file or one folder. In Gramps, a single media object (e.g., a 19th-century census manifest) can be linked simultaneously to multiple people, events, places, and sources without duplicating the metadata or the file itself.
  • Database Amalgamation: Instead of scattering thousands of .xmp files across your hard drive, Gramps aggregates all media metadata into your family tree database file (or packages them together only when you explicitly export a .gpkg archive).
  • Genealogical Depth: Standard sidecars track technical data, tags, and cropping coordinates. Gramps extends this “sidecar” concept into deep historical provenance—linking media directly to citations that prove why a specific document validates a genealogical claim.

Summary

If traditional sidecars are decentralized sticky notes attached to individual files, Gramps functions as an amalgamated, master metadata ledger. It virtualizes the sidecar concept, pulling all descriptive, relational, and historical data into a unified database while using file paths and checksums to keep an arm’s-length connection to your actual media library.