De exporter (shaer-1a6)
ArchiveExportService bouwt het archief uit docs/EXPORT-FORMAT.md, plus een CLI
(scripts/export-archive.mjs) met een droogloop.
Alleen de eigen posts van de site, inclusief concepten. Geen sleutel, sessie,
wachtwoordhash of DM van een ander -- dit is nadrukkelijk niet de storage-zip uit
shaer-190t.
Media worden gesleuteld op de sha256 van hun bytes, zodat twee exports dezelfde
namen opleveren en dubbelen vanzelf samenvallen. Een verdwenen bestand krijgt de
derde staat uit het formaat -- 'missing', met de oorspronkelijke plek erbij -- en
wordt geteld en gemeld, nooit stil weggelaten.
Zip zonder nieuwe afhankelijkheid: store-only, gesorteerde ingangen, vaste mtime.
Zonder compressie is byte-gelijkheid geen kwestie van vertrouwen in de
instellingen van een bibliotheek. Gecontroleerd dat gewone unzip hem uitpakt en
dat de bytes er identiek uitkomen; een zelfgeschreven zip die alleen zichzelf kan
lezen is geen uitwisselformaat.
Twee dingen kwamen pas boven bij het draaien tegen echte data (beta):
- een audio-bijlage in c2s_attachments draagt naast url ook een POSTER, en die
viel er stil uit. Nu meegenomen; media op beta gingen daarmee van 2 naar 3.
- het [[track:]]-pad raakt op beta geen enkele rij (nul audio_tracks), dus dat
heeft nu een eigen test in plaats van de aanname dat het meeliep.
Een verzonnen pad in oude inhoud kan geen willekeurig bestand van de schijf het
archief in trekken: media-URL's worden binnen MEDIA_ROOT gehouden en een URL naar
een andere host wordt nooit van onze eigen schijf gelezen.
De reproduceerbaarheidseis in het formaat sloot exportedAt niet uit en sprak
zichzelf daarmee tegen; dat is rechtgezet.
15 tests, waaronder de acceptatietest uit het document: de moeilijkste post die
Klonkt kan maken (poll, bijlagen, quote, content warning, betaald). Suite 493/493.
Co-Authored-By: Claude Opus 5 <noreply@…>
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
