docs(bern52): record that all six drives went to long-term storage - #236
Conversation
Written where a gap will be noticed. Somebody who cannot find a file in legacy/ reads this page, and the question they are actually asking is whether the data is missing or whether the disk is in a drawer. A session log dated 2026-09-21 does not answer that in 2027. Nothing was mid-transfer at the time: the newest file copied off any of the six is dated 2026-09-08 18:39:38 and no legacy file has arrived since. Fixity does not depend on the disks staying docked -- legacy/ carries committed sha256 manifests. New Volume is called out as the one to re-dock if a gap appears. It is the only one of the six whose contents are not in legacy/, and the basename comparison that justified skipping it is conclusive in one direction only: nothing on it is uniquely NAMED. Two files sharing a name can still differ, and this archive has twice shown that a name is not an identity. The section above already says so; the storage record repeats it because that is the moment the distinction matters.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
alfieprojectsdev
left a comment
alfieprojectsdev
left a comment
There was a problem hiding this comment.
Verdict: approve. Both figures are mine and both re-check out.
newest legacy file by ctime /srv/gnss-archive/legacy/RECOVERED_SEAGATE_W2A0W9T2_DC9A88/
Users/Decollement/Desktop/ToLizeth/puer3121.13o.gz
2026-09-08 18:39:38
legacy files created after 1,449 (726 SEAGATE_.../RAW, 715 GPS_1TB_2/$RECYCLE.BIN,
2026-09-05 8 SEAGATE_.../Users)
Measured by os.stat over every legacy/ path in the 480,178-row attribution CSV, none missing. It's a creation-time check, not modification time: those transfers preserved the source mtime, so an mtime check would have come up 1,449 short and read as "nothing arrived recently" for the wrong reason.
The README is the right home and I was wrong to propose the session log. Your reason is the deciding one: the reader is someone who can't find a file in legacy/ and needs to know whether it's missing or in a drawer. A log entry dated 2026-09-21 doesn't answer that in 2027. Changing the destination of my item without asking was correct.
Fixing the "It may still be docked" line in the same change matters more than it looks. That sentence was the stale half of the same shape as this week's other two: true when written, outliving the event, sitting in the document people are sent to.
One factual note, not a change request. The table's New Volume row and the line beneath it are accurate about names. Worth knowing what the basename comparison rests on: this archive has twice shown a name isn't an identity, because Leica .mNN and Trimble .T0x names carry no year, so the same name recurs across years. The PR already says the comparison is conclusive in one direction only, which is the part that matters.
I did not unmount anything, and nothing was at risk. My check on gps3 was read-only (lsblk, lsusb, findmnt) and found no RECOVERED_* mount point and no USB mass storage, which is consistent with your cable finding: nothing was ever enumerated on either machine.
Reviewed from gps3.
This branch was successfully deployed
1 participant
Alfie asked for the docked external drives to go back into long-term storage, and authorised it directly as well as through gps3.
Where the record goes, and why not a session log. gps3 proposed the session log. This puts it in
docs/bern52/README.mdinstead, because the person this record exists for is someone who cannot find a file inlegacy/and needs to know whether it is missing or whether the disk is in a drawer. That person reads this page. A session log dated 2026-09-21 does not answer them in 2027.What is recorded: the six drives by the identifiers they carry in
legacy/, which of them are actually held there, the date, and the fact that nothing was mid-transfer — newest file copied off any of them ispuer3121.13o.gzat 2026-09-08 18:39:38, with no legacy file since. Fixity does not depend on the disks:legacy/has committed sha256 manifests.New Volumeis flagged as the one to re-dock if a gap ever shows. It is the only one of the six whose contents are not inlegacy/, and the basename comparison that justified skipping it is conclusive in one direction only — nothing on it is uniquely named. Two files sharing a name can still differ, and this archive has twice demonstrated that a name is not an identity (Leica.mNN, Trimble.T0x). §1 already says this; the storage record repeats it, because unplugging the disk is the moment the distinction starts to matter.Also corrects "It may still be docked" for that drive, which is now answered.
No unmount was needed, and that is not the same as skipping one
The drives are physically at finch, in a dock that was powered on with the USB cable never plugged in — Alfie spotted it. So the kernel never enumerated them this session:
lsblkshows two internal SATA SSDs only (sdasystem,sdb/mnt/ssd), no USB storage onlsusb, no/mediaor/run/mediamounts,/media/finchempty, bothsd*reportingtran=sata removable=0.No filesystem was ever mounted, so there is nothing to flush and nothing that can be half-written.
lsof +Dandumounthave no target. Plugging the cable in now would create the mount that then needs a clean unmount, so the right action is to power the dock down with the cable still out.Corrected from an earlier version of this description, which said the unmount was gps3's to perform. That was wrong: gps3 said the steps were on finch and it was right — I inferred from "nothing is mounted" that the drives must be on the other machine, when the actual cause was an unplugged cable. The manifests'
/run/media/finch/<LABEL>/path prefix was already evidence that these drives dock here.