v0.7.0

Four questions this could not answer before, and all four are answered in the database rather than in the browser. That distinction is the release: the activity log runs to tens of thousands of rows, the screen holds a few dozen, and filtering what was already fetched searches the last page instead of the log.

✨ Added

• Search the activity log by path. "Which run touched that file" was not answerable at all: the log shows the newest few dozen entries and a file touched a thousand rows ago was simply gone. The search narrows at the server, so a name from three weeks back comes back on the first press. It escapes LIKE's own wildcards, which is less pedantic than it sounds - an unescaped a_b matches urlaub, because the underscore means "any one character" and paths are full of both. The box stays on screen when a search finds nothing, so a mistyped letter still has a way back to the full list.

• Narrow the history to a stretch of days. "What happened at the weekend" had the same problem from the other end: a job watching a folder writes a run a minute, so ten thousand rows sit between Friday and Monday and the only way back through them was to keep asking for more. Two calendar days, either of which may be left blank for an open end, and both blank is the plain newest-first list it has always been. The upper bound is the LAST instant of its day rather than its midnight, so "up to the 3rd" no longer hides everything that happened on the 3rd.

• How full a target is. The question people have BEFORE a sync rather than after: a job copying eighty gigabytes onto a cloud drive with twelve left fails eighty gigabytes in, having spent an evening on it. Shown on the same press as the connection check, so it costs nothing until somebody asks. Most cloud targets cannot answer - a bucket store has no quota to report and will take another terabyte - and those are reported as not knowing rather than as empty, because "no limit at all" and "nothing free" must never render the same.

• Find duplicate files. The same holiday photos under three names, an archive unpacked twice, a backup of a backup. It reports and never deletes: which of three identical files is the one to keep is a decision about what your folders mean, and the copy in urlaub/ and the copy in backup/ are the same bytes and not the same thing. Per side rather than per job, because a job's two sides are supposed to hold the same files. Sets are listed biggest-waste-first, with what deleting the extra copies would actually return - counting every copy but the first, since the first one is the file rather than a duplicate of it. Files the target cannot checksum are counted and named, because that is the one thing that makes the answer incomplete.

• A saved target is asked whether it answers. Saving a target proved nothing: a typo in an address or a password with a trailing space was written to the file as happily as a working one, and the first anybody heard of it was a failed run at three in the morning. The check now runs on save and reports what the server said. It never blocks - a server that is switched off right now is not a mistake, and closing the form stays your decision.

⚡ Improved

• The About card's prose runs the width of its card. It was the only capped text on its page, so three paragraphs stopping two thirds of the way across read as hand-set line breaks rather than as a measure.