mirror of
https://github.com/runbear-io/beardrive.git
synced 2026-08-25 08:08:08 +02:00
`mv a.md b.md` produced two rows minutes apart: the delete carried the rename's time, the put carried the original file's mtime, so a file that appeared seconds ago sorted below the fold of "what changed since yesterday" — the question `bdrive log` exists to answer. SortForDisplay now orders by CommitTime (when the change was journaled), tie-breaking on DisplayTime so one scan still reads by the files' own edit times. The write time is still shown, appended as `written <time>` when it lags the commit by more than a minute — a rename, or an old document added today — rather than silently replacing the column. DisplayTime and both of its security clamps are untouched. CommitTime carries the same clamp: an op stamped after this machine's clock cannot date itself, so it sorts last rather than first. One deviation from the plan: it assumed a scan shares one commit time, but nextOp stamped time.Now() per op, so the tie-break never engaged and one scan sorted in walk order. A scan is now one commit instant — order inside the batch is already carried by Lamport and Seq, which journal.Less reads first, so replay is unaffected. journal.Less, Replay, LogEntries' causal order and the op format are unchanged. The hub's History is a separate path and still orders a rename by write time.