Documentation
Data and storage
AFTRIMGE keeps everything it records on your computer. Its own code makes no network requests, has no account, and sends no telemetry.
Where the archive lives
| Copy | Archive location |
|---|---|
| Windows, installed | %APPDATA%\com.aftrimge.desktop\ |
| Windows, portable | AFTRIMGE Data\ beside AFTRIMGE.exe |
| Linux | ~/.local/share/com.aftrimge.desktop/ |
The exact path is shown in the Memory panel, and as a tooltip on the status bar.
On Linux the archive folder is created so that only your account can open it. On Windows, %APPDATA% is already private to your account; a portable copy's AFTRIMGE Data folder has whatever permissions the folder you extracted it to has.
AFTRIMGE never stores its archive inside a folder it is watching, and refuses to watch a folder that contains its archive.
What is in it
| Item | What it is | If it is lost |
|---|---|---|
aftrimge.db (and aftrimge.db-wal, aftrimge.db-shm) | The temporal index: projects, files, versions, events, preservation decisions, analysis results, the maintenance log | History is gone. Not reconstructable. |
objects/ | Every retained version's bytes, stored once per distinct content under its SHA-256 identity | Those versions cannot be restored. Their history remains and reads as missing. |
thumbnails/, diffs/ | Previews and rendered comparisons | Nothing. Regenerated on demand. |
metadata/ | Reserved | Nothing. |
aftrimge.lock | Held by the operating system while AFTRIMGE has the archive open, so a second copy cannot open it. Do not delete it. | Nothing. Recreated on next launch. |
backups/ | Copies of aftrimge.db made before a database format upgrade; the newest 3 are kept | The upgrade backups. The archive itself is unaffected. |
logs/ | One engine log per day, and panic.log if AFTRIMGE has failed internally | Troubleshooting detail only. |
| Web view cache | The embedded browser's own storage: webview/ in a portable copy, %LOCALAPPDATA%\com.aftrimge.desktop\EBWebView for an installed Windows copy, and folders such as WebKitCache inside the archive folder on Linux | Nothing. Recreated on next launch. |
Committed data can sit in aftrimge.db-wal until SQLite folds it into aftrimge.db. The two files belong together.
Canonical content, historical observations and derived information
AFTRIMGE keeps these apart, and so does this documentation.
- Canonical content is an object: bytes addressed by their SHA-256 digest. Its identity and its size come from the bytes, never from what a caller claimed.
- Historical observations are what was recorded at the time: a file's path then, the size a snapshot saw, when an event happened. They are kept as they were observed and are not rewritten when something later changes.
- Derived information is computed from the other two: thumbnails, image measurements, relationship grades, continuity traces. It can be recomputed, and it is never presented as if it had been observed.
Deduplication
Identical content is stored once, however many versions, files or projects contain it. Two files with the same bytes share one object.
Snapshots, retention and collection
- A snapshot is one recorded version of one file: which content it had and when.
- Retention can release the stored bytes of versions older than a cutoff. The newest version of a file that still exists is never released. Releasing keeps the version, its event and its name in history; only the bytes become eligible for removal.
- Collection (a sweep) deletes bytes that nothing holds any more. It is a separate action you run, and it can be previewed first.
What holds content
Content is kept while at least one of these points at it:
| Holder | Meaning |
|---|---|
SNAPSHOT | A retained version of a watched file |
ARCHIVED_ARTIFACT | An image you imported and chose to keep |
PRESERVATION | A decision you recorded to keep specific content |
The storage ledger lists every piece of content with one of four states:
| State | Meaning |
|---|---|
HELD | Something holds it; a sweep will not remove it |
RECLAIMABLE | Nothing holds it; a sweep may remove it |
MISSING | AFTRIMGE knows this content and its bytes are not on disk |
UNTRACKED | Bytes on disk AFTRIMGE has no record of |
A MISSING row is not a leak. It is the record that content existed and its bytes are gone, and it is kept on purpose.
Bytes with no record are only removed by a sweep once they are at least 15 minutes old, so a sweep does not remove content that is still being captured.
Logs
Daily logs are named logs/aftrimge.log.YYYY-MM-DD. AFTRIMGE keeps the newest 14 days of them, and also removes older days' logs once those exceed 64 MB in total. Today's log is never removed. This pruning runs at startup and once a day.
Log files contain file paths inside your projects and each project's full folder path. They are not sent anywhere.
logs/panic.log holds a short record of each internal failure: time, version, thread, source location and message. Once it passes 256 KB it is started afresh and the previous file is kept as panic.log.1.
Diagnostic report
The Diagnostics button on the status bar writes a JSON report only when you ask, to a place you choose. It holds version, format and platform details, counts and sizes, the database's quick_check result, log file names and sizes, the number of crash records, and up to the last 400 log lines with their values redacted. It holds no file contents, file names, paths, project names, folder locations, archive location, or account or computer names. See Recovery and restore.
How much space it uses
The Memory panel shows the archive's size on disk, how much of it versions would take if each were stored separately, and what a sweep would reclaim. AFTRIMGE does not limit how large the archive grows. A single file larger than 256 MiB has its version recorded without its bytes being retained.
When the disk is full
Write failures are reported as errors and the operation stops. This was tested with a simulated full disk (writes made to fail as a full disk would), not on a real full volume:
- adding content to the store admits nothing and leaves no staging file;
- a restore leaves the existing file untouched and no temporary file;
- exporting a version or a diagnostic report leaves any existing destination file as it was and no partial file, because exports are written to a temporary file and then renamed;
- the backup before a database format upgrade fails and the upgrade does not happen;
- writing the crash record fails quietly.
Encryption
The archive is not encrypted. It is as readable as your own files. Use the operating system's disk encryption if that matters to you.
Source: docs/DATA_AND_STORAGE.md