fix(crop): draaien op Windows lukte niet omdat de voorvertoning het bestand vasthield #1782

Merged

brenno merged 1 commit from fix/crop-preview-uit-geheugen into main

2026-08-24 22:17:04 +00:00

brenno commented

2026-08-24 22:10:46 +00:00

Owner

Het mechanisme, eindelijk

FileImage._loadAsync laat de engine het bestand openen met ui.ImmutableBuffer.fromFilePath — na te lezen in image_provider.dart van de gepinde Flutter. Op Windows is dat een geheugenafbeelding, en zolang die leeft weigert Windows het bestand te vervangen of te verwijderen.

Het bijsnijdvenster toonde dus een afbeelding op precies het bestand dat het straks ging overschrijven. rename mislukte, de terugval mocht het doel niet verwijderen (errno 32), en de schrijffout werd ingeslikt: de preview draaide, het bestand bleef, en er kwam geen melding.

Dit is een echte gebruikersbug op Windows, geen testartefact. De CHANGELOG-regel waarin ik dat laatste beweerde is ingetrokken.

Waarom mijn drie eerdere pogingen niets deden

#1763 — de ontbrekende Windows-terugval in de sync-schrijver. Nodig (de bibliotheekdoc beloofde hem al), maar niet de oorzaak.
#1776 — de beeldcache loslaten en blokkerend herkansen. Een levende geheugenafbeelding laat je niet los door te wachten.
#1781 — tester.runAsync in de toets. Onschadelijk, maar het beschreef de verkeerde oorzaak.

Elke ronde gaf de spiegel dezelfde melding terug; ik heb hem drie keer verkeerd geduid. De diagnose uit #1774 is wat dit uiteindelijk oploste — zonder die reden had ik het nog een keer verkeerd geraden.

De reparatie

Het venster voedt zijn voorvertoning uit de bytes die het voor het draaien tóch al inleest. Geen FileImage meer op het bestand dat we herschrijven, en één leesbeurt in plaats van twee. Bundled assets en mem:-paden houden hun bestaande route.

Toetsing — lees dit

De crop-toetsen zijn groen, en de rest van de suite ook, op één na: document_editor_screen_test.dart: "Visueel: rauwe HTML schakelt automatisch naar Bron-modus met uitleg". Die staat sinds ~16:20 op 24-08 rood op main zelf (drie merges op rij: 08ca0525, 7aeb6b6d, ec24b6c3), faalt ook op een schone main zonder mijn wijziging, en heeft niets met deze PR te maken. make check is dus groen op alles wat van mij is en rood op dat ene punt dat ik hier niet oplos.
Dat is geen verouderde assertie: MarkdownNotesEditor ís de Visuele modus, en de toets eist juist dat rauwe HTML naar Bron-modus schakelt in plaats van stilletjes naar brontekst binnen de visuele modus. Welke van de twee de bedoeling is, is een ontwerpkeuze van de documenteditor — daar ga ik niet overheen schrijven.
Dat déze reparatie werkt, bewijst de eerstvolgende spiegel-run; de diagnose blijft staan, dus als het weer misgaat noemt hij opnieuw de reden.

Bewaker

Overgeslagen, expliciet: geen formaat, opslag, afhankelijkheid of publieke belofte. Wel iets minder IO en iets minder geheugen-op-schijf-gedrag, beide de goede kant op.

## Het mechanisme, eindelijk `FileImage._loadAsync` laat de engine het bestand openen met `ui.ImmutableBuffer.fromFilePath` — na te lezen in `image_provider.dart` van de gepinde Flutter. Op Windows is dat een **geheugenafbeelding**, en zolang die leeft weigert Windows het bestand te vervangen of te verwijderen. Het bijsnijdvenster toonde dus een afbeelding op precies het bestand dat het straks ging overschrijven. `rename` mislukte, de terugval mocht het doel niet verwijderen (errno 32), en de schrijffout werd ingeslikt: de preview draaide, het bestand bleef, en er kwam geen melding. **Dit is een echte gebruikersbug op Windows**, geen testartefact. De CHANGELOG-regel waarin ik dat laatste beweerde is ingetrokken. ## Waarom mijn drie eerdere pogingen niets deden - #1763 — de ontbrekende Windows-terugval in de sync-schrijver. Nodig (de bibliotheekdoc beloofde hem al), maar niet de oorzaak. - #1776 — de beeldcache loslaten en blokkerend herkansen. Een levende geheugenafbeelding laat je niet los door te wachten. - #1781 — `tester.runAsync` in de toets. Onschadelijk, maar het beschreef de verkeerde oorzaak. Elke ronde gaf de spiegel dezelfde melding terug; ik heb hem drie keer verkeerd geduid. De diagnose uit #1774 is wat dit uiteindelijk oploste — zonder die reden had ik het nog een keer verkeerd geraden. ## De reparatie Het venster voedt zijn voorvertoning uit de bytes die het voor het draaien tóch al inleest. Geen `FileImage` meer op het bestand dat we herschrijven, en één leesbeurt in plaats van twee. Bundled assets en `mem:`-paden houden hun bestaande route. ## Toetsing — lees dit - De crop-toetsen zijn groen, en de rest van de suite ook, **op één na**: `document_editor_screen_test.dart: "Visueel: rauwe HTML schakelt automatisch naar Bron-modus met uitleg"`. Die staat sinds ~16:20 op 24-08 rood op `main` zelf (drie merges op rij: `08ca0525`, `7aeb6b6d`, `ec24b6c3`), faalt ook op een schone `main` zonder mijn wijziging, en heeft niets met deze PR te maken. `make check` is dus groen op alles wat van mij is en rood op dat ene punt dat ik hier niet oplos. - Dat is geen verouderde assertie: `MarkdownNotesEditor` ís de Visuele modus, en de toets eist juist dat rauwe HTML naar Bron-modus schakelt in plaats van stilletjes naar brontekst binnen de visuele modus. Welke van de twee de bedoeling is, is een ontwerpkeuze van de documenteditor — daar ga ik niet overheen schrijven. - Dat déze reparatie werkt, bewijst de eerstvolgende spiegel-run; de diagnose blijft staan, dus als het weer misgaat noemt hij opnieuw de reden. ## Bewaker Overgeslagen, expliciet: geen formaat, opslag, afhankelijkheid of publieke belofte. Wel iets minder IO en iets minder geheugen-op-schijf-gedrag, beide de goede kant op.

brenno added 1 commit

2026-08-24 22:10:46 +00:00

fix(crop): draaien op Windows lukte niet omdat de voorvertoning het bestand vasthield

scans / scans (pull_request) Successful in 2m1s

Details

static-gate / static-gate (pull_request) Successful in 6m5s

Details

8e3d8e5f19

Vierde poging, en de eerste met een mechanisme in plaats van een vermoeden.

`FileImage` laat de engine het bestand openen met
`ui.ImmutableBuffer.fromFilePath` (zie image_provider.dart in de gepinde
Flutter). Op Windows is dat een geheugenafbeelding, en zolang die leeft weigert
Windows het bestand te vervangen of te verwijderen. Het bijsnijdvenster toonde
dus een afbeelding op precies het bestand dat het straks ging overschrijven:
`rename` mislukte, de terugval mocht het doel niet verwijderen (errno 32), en de
schrijffout werd ingeslikt. De gebruiker zag de preview draaien en hield een
bestand dat onveranderd bleef.

Dat verklaart ook waarom mijn drie eerdere pogingen niets uithaalden: de
beeldcache legen laat een levende geheugenafbeelding niet los, en wachten — of
het nu blokkerend of asynchroon is — evenmin. De Windows-CI heeft dat drie keer
laten zien; ik heb het drie keer verkeerd geduid.

De reparatie: het venster voedt zijn voorvertoning uit de bytes die het voor het
draaien tóch al inleest. Geen FileImage meer op het bestand dat we herschrijven,
en één leesbeurt in plaats van twee. Bundled assets en `mem:`-paden houden hun
bestaande route.

De CHANGELOG-regel die dit als een probleem van de testomgeving afdeed is
ingetrokken: het was een echte fout voor iedereen die OciDeck op Windows
gebruikt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

brenno merged commit a460c8965b into main

2026-08-24 22:17:04 +00:00

brenno referenced this pull request from a commit

2026-08-24 22:17:04 +00:00

fix(crop): draaien op Windows lukte niet omdat de voorvertoning het bestand vasthield (#1782)