Skip to main content
栞Docs
Contents

Game fingerprints

How GalShelf recognises releases and editions from their files, what is hashed, what stays on your computer and what the two separate consents mean.

  • Desktop appAvailable in 0.2.8
  • WebsiteAvailable
On this page
  1. What is hashed
  2. How fingerprints identify works
  3. Online lookup
  4. Contributing fingerprints
  5. Privacy
  6. Trust levels
  7. A fingerprint is not a safety check
  8. Location learning and control

A game fingerprint is the SHA-256 digest and size of selected files in an installed game. GalShelf uses fingerprints to recognise which release (and which edition) a folder contains, so matching and deduplication can rely on the files themselves rather than only on folder names:

Installation → release fingerprint → release / edition → work → VNDB / NextMoe IDs

You find it on a work's page under 文件与完整性 / Files & integrity, and the choices in Settings → 隐私与安全 / Privacy & Security.

What is hashed#

  • Desktop appAvailable in 0.2.8
  • WebsiteNot applicable

GalShelf does not hash your whole game folder. After cheap checks on names, sizes and executable metadata, it hashes only a few candidate files per installation: the launch executable and any launcher, engine runners, and small companion files that help tell releases apart. It also records a structural signature made of the names and sizes of the engine's archive files (such as *.xp3 or *.pck) in the game folder and one level below. Saves, screenshots and changeable settings files are ignored.

Hashing runs in the background with limited disk use and can be cancelled. Results are cached by file identity, size and modification time, so unchanged files are not read again; a full recheck ignores the cache. Files that change while being read, moved or renamed files, removable drives and unreadable files are detected and reported instead of producing a wrong digest.

How fingerprints identify works#

  • A fingerprint points to a release, not directly to a work. The same work can have several releases and editions, and each installation keeps its own identity.
  • Shared engine executables (for example SiglusEngine or RealLive) are used by many titles, so they never identify a title on their own; other evidence from the same folder is needed.
  • One file can be claimed by conflicting releases. GalShelf keeps and shows the conflict instead of picking one silently.
  • Unknown fingerprints fall back to the normal matching flow, where you confirm the work (see Library and import).
  • Recognising two folders as the same work is a link you can review. It never deletes or merges game files, play history or Steam records.

Online lookup#

  • Desktop appAvailable in 0.2.8
  • WebsiteAvailable
  • The lookup service runs on galshelf.com; its database starts empty and grows from maintainer manifests and confirmed contributions.

Online lookup has its own Privacy & Security switch. Cloud Saves setup explains lookup and contribution and selects both initially; any earlier explicit choice is preserved. Starting or upgrading GalShelf does not opt you in. After you enable lookup, eligible checked installations can be looked up automatically; Look up online is also available:

  • It sends the SHA-256 digests and sizes of the installation's hashed candidate files, and nothing else.
  • The answer lists candidate releases with their trust level and whether reports conflict.
  • Without the service, GalShelf uses the local cache and any maintainer manifests you imported. An empty database is fine: GalShelf simply falls back to normal matching. Until the service is live, the page says the service doesn't offer this feature yet.

Contributing fingerprints#

  • Desktop appAvailable in 0.2.8
  • WebsiteAvailable

Contribution is a separate consent. Cloud Saves setup shows its initially selected control alongside online lookup, preserving previous explicit opt-outs. You can disable either one without disabling Cloud Saves or local identification.

After the setup disclosure, eligible independently confirmed evidence can be sent automatically without a per-file prompt. The activity view shows pending work and the last outcome; manual submissions still have a preview. Contributions contain:

  • the digest and size, and the file's role (for example "launch executable");
  • the public VNDB work ID and, when known, the release ID;
  • independently obtained confirmation provenance; a recycled online answer or unsigned imported reviewer name is not an independent report;
  • where available, a supported generic save-location form, its public release ID and existing game-file anchors. No save hash is contributed;
  • the bare file name, only if you tick the option to include it.

Privacy#

Never sent, for lookup or contribution:

  • absolute paths, usernames, custom folder labels, private relative path segments, save-file lists or save hashes,
  • your account name or hardware identifiers,
  • game files or any file contents.

A contribution is sent with your GalShelf desktop sign-in (the session token and the random session binding the service issued when you signed in, as every account request carries) so the service can limit abuse and duplicate reports. It is therefore not anonymous toward the GalShelf service, with minimized report data and a pseudonymous account-derived reporter key retained for abuse prevention. Lookups don't need an account.

Trust levels#

Each mapping has an evidence state: 候选 / Candidate, 较可信 / Likely or 已审核 / Reviewed.

  • A match you confirm yourself counts as Likely on your computer.
  • On the service, Likely needs reports from at least three different accounts, and Reviewed needs a maintainer. Repeated reports from one client or one account never promote a mapping.
  • Contradicting reports are kept aside for review, not merged.
  • Unsigned imported manifests remain local identity hints, even if they name a reviewer. They cannot grant automatic save-write authority.
  • Reviewed location rules require independent reproduction and exact family anchors, then a purpose-bound signature using GalShelf's update trust root. The client enforces revision, expiry, revocation, compatible release and local path boundaries. Crowd counts do not authorize restoration.
  • GalShelf doesn't show invented confidence percentages.

A fingerprint is not a safety check#

Location learning and control#

Identity, save compatibility, location trust and file integrity are shown separately. A modified or flagged EXE can be excluded while unaffected known companion anchors still identify the release. Its new hash is not contributed as a clean sample. Guard and antivirus warnings remain in force.

Location reports use a small set of generic forms such as {install_dir}/savedata or {locallow}/{unity_company}/{unity_product}. Token values stay on your computer. Custom literal names cannot be submitted through this automatic channel. A manually selected folder alone does not prove that the game saves there: a real user-started game session must supply local activity.

Turning contribution off discards unsent contributions, and authorization is checked again just before transmission. Sign-out or account change cancels work associated with the old session. Offline retries and queue size are bounded and do not block provider backups. Private reports can be withdrawn from the service; independently reviewed rules already published may remain. Disabling contribution does not delete provider saves or local history.