[Bug] Error message when saving

kwoot commented

2026-09-01 07:43:43 +00:00

Describe the bug
Using ocideck appimage, saving a test presentation gives error message. see screemshot

To reproduce
Steps to reproduce the behaviour:

add a second storage location. The directory name is identical to the first storage location but on a different path
save the presentation to that storage location
See error message

Expected behaviour
No error message

Screenshots / sample deck
See below

Environment

OciDeck version: 0.4.10
OS and version: ubuntu 24.04
Flutter version (flutter --version): unknown
Single or dual screen (if presenter-related): not relevant

Additional context
Nope

For security vulnerabilities, do not open a public issue — see
SECURITY.md.

**Describe the bug** Using ocideck appimage, saving a test presentation gives error message. see screemshot **To reproduce** Steps to reproduce the behaviour: 1. add a second storage location. The directory name is identical to the first storage location but on a different path 2. save the presentation to that storage location 3. See error message **Expected behaviour** No error message **Screenshots / sample deck** See below **Environment** - OciDeck version: 0.4.10 - OS and version: ubuntu 24.04 - Flutter version (`flutter --version`): unknown - Single or dual screen (if presenter-related): not relevant **Additional context** Nope > For **security vulnerabilities**, do not open a public issue — see > [SECURITY.md](../../SECURITY.md).

Screenshot from 2026-09-01 09-39-50.png

11 KiB

kwoot added the

bug

label

2026-09-01 07:43:43 +00:00

brenno added the

in-progress

label

2026-09-01 11:00:35 +00:00

brenno commented

2026-09-01 11:14:14 +00:00

Owner

Dank voor de melding en vooral voor de schermafdruk — die wees precies de goede kant op.

Ik heb hem gereproduceerd. De oorzaak zit niet in de tweede opslaglocatie: de melding komt van een controle in het open-pad. Na het opslaan leest OciDeck het zojuist geschreven bestand terug (om de genormaliseerde vorm op te pakken en de bytes opnieuw te scannen). Die teruglezing weigerde een bestand met front matter maar zonder diablok, omdat dat gold als 'afgekapt'. Een presentatie waarvan de enige dia nog leeg is, schrijft OciDeck echter precies zo weg — dus las het opslaan zijn eigen bestand niet meer terug. Je bestand is in orde; alleen de melding klopte niet. Hetzelfde bestand opnieuw openen lukte overigens ook niet, en dat was het ergere deel.

In behandeling op tak fix/1909-save-reread; raakt lib/services/file_service.dart en lib/services/file/file_service_open.dart.

Eén vraag, om zeker te weten dat ik jouw geval te pakken heb en niet alleen een geval dat er hetzelfde uitziet: had de presentatie die je opsloeg al inhoud (een titel, opsommingstekens), of was hij nog leeg?

Dank voor de melding en vooral voor de schermafdruk — die wees precies de goede kant op. Ik heb hem gereproduceerd. De oorzaak zit niet in de tweede opslaglocatie: de melding komt van een controle in het open-pad. Na het opslaan leest OciDeck het zojuist geschreven bestand terug (om de genormaliseerde vorm op te pakken en de bytes opnieuw te scannen). Die teruglezing weigerde een bestand met front matter maar zonder diablok, omdat dat gold als 'afgekapt'. Een presentatie waarvan de enige dia nog leeg is, schrijft OciDeck echter precies zo weg — dus las het opslaan zijn eigen bestand niet meer terug. Je bestand is in orde; alleen de melding klopte niet. Hetzelfde bestand opnieuw openen lukte overigens ook niet, en dat was het ergere deel. In behandeling op tak `fix/1909-save-reread`; raakt `lib/services/file_service.dart` en `lib/services/file/file_service_open.dart`. Eén vraag, om zeker te weten dat ik jouw geval te pakken heb en niet alleen een geval dat er hetzelfde uitziet: had de presentatie die je opsloeg al inhoud (een titel, opsommingstekens), of was hij nog leeg?

brenno referenced this issue from a commit

2026-09-01 11:30:57 +00:00

fix(opslaan): front matter zonder body is een lege presentatie, geen kapotte (#1909)

brenno referenced this issue from a commit

2026-09-01 11:30:57 +00:00

docs: de truncatie-heuristiek is weg, en dat staat nu ook in de documentatie (#1909)

brenno referenced this issue

2026-09-01 11:31:34 +00:00

fix(opslaan): front matter zonder body is een lege presentatie, geen kapotte (#1909) #1910

brenno referenced this issue from a commit

2026-09-01 11:37:46 +00:00

fix(opslaan): front matter zonder body is een lege presentatie, geen kapotte (#1909) (#1910)

brenno commented

2026-09-01 11:38:08 +00:00

Owner

Opgelost en gemerged: b140c8cb4 (PR #1910).

Wat het was. Niet de tweede opslaglocatie. Na het opslaan leest OciDeck het zojuist geschreven bestand terug, en die teruglezing weigerde front matter zonder diablok als 'afgekapt bestand'. Dat is nu juist precies wat OciDeck zélf wegschrijft voor een presentatie waarvan de enige dia nog leeg is — een lege dia serialiseert naar niets. Het opslaan las dus zijn eigen bestand niet terug. Erger nog, en dat stond niet in de melding: hetzelfde bestand daarna opnieuw openen lukte ook niet.

Wat er nu gebeurt. Front matter zonder body opent als lege presentatie. Afgekapt en leeg zijn in de bytes niet van elkaar te onderscheiden, dus viel er niets te verfijnen — alleen te kiezen. Wat OciDeck schrijft moet OciDeck kunnen teruglezen, en een .md met alleen front matter is bovendien geldige Marp die een andere editor mag aanreiken. Wat we ervoor opgeven is de mélding bij een echt afgekapt bestand, niet de inhoud: die was daar al weg vóór wij hem lazen. De afweging staat voluit in PR #1910 en in de CHANGELOG.

Gold ook via git en WebDAV, waar dezelfde weigering het eigen opgeslagen werk trof. Regressietoets: test/bug_1909_empty_deck_roundtrip_test.dart — de derde toets reproduceert jouw schermafdruk letterlijk.

Wat er niet in zat. Je stap met de tweede opslaglocatie heb ik nagelopen: die is geen oorzaak. Verbindingen worden op uuid gesleuteld, de bibliothekenlijst mapt één-op-één en de bestemmingsdialoog selecteert op pad — twee mappen met dezelfde naam kunnen elkaar niet verdringen. Je waarneming klopte alleen niet je verklaring, en dat is precies de nuttige helft.

Er is nog één andere weg naar dezelfde melding, die deze reparatie niet dekt: wie zelf <script> of <iframe> in een vrije-Markdown-dia typt, krijgt hem ook — de veiligheidsscan weigert dan de teruglezing, terecht, maar de melding zegt niet waarom. Dat wordt een eigen issue.

Zit je in de v0.5.0-release. Dank voor de melding; je staat in de CHANGELOG. Wil je ook in CONTRIBUTORS.md, laat dan even weten onder welke naam — die vul ik niet zelf in.

Opgelost en gemerged: `b140c8cb4` (PR #1910). **Wat het was.** Niet de tweede opslaglocatie. Na het opslaan leest OciDeck het zojuist geschreven bestand terug, en die teruglezing weigerde front matter zonder diablok als 'afgekapt bestand'. Dat is nu juist precies wat OciDeck zélf wegschrijft voor een presentatie waarvan de enige dia nog leeg is — een lege dia serialiseert naar niets. Het opslaan las dus zijn eigen bestand niet terug. Erger nog, en dat stond niet in de melding: hetzelfde bestand daarna opnieuw openen lukte ook niet. **Wat er nu gebeurt.** Front matter zonder body opent als lege presentatie. Afgekapt en leeg zijn in de bytes niet van elkaar te onderscheiden, dus viel er niets te verfijnen — alleen te kiezen. Wat OciDeck schrijft moet OciDeck kunnen teruglezen, en een `.md` met alleen front matter is bovendien geldige Marp die een andere editor mag aanreiken. Wat we ervoor opgeven is de mélding bij een echt afgekapt bestand, niet de inhoud: die was daar al weg vóór wij hem lazen. De afweging staat voluit in PR #1910 en in de CHANGELOG. Gold ook via git en WebDAV, waar dezelfde weigering het eigen opgeslagen werk trof. Regressietoets: `test/bug_1909_empty_deck_roundtrip_test.dart` — de derde toets reproduceert jouw schermafdruk letterlijk. **Wat er niet in zat.** Je stap met de tweede opslaglocatie heb ik nagelopen: die is geen oorzaak. Verbindingen worden op uuid gesleuteld, de bibliothekenlijst mapt één-op-één en de bestemmingsdialoog selecteert op pad — twee mappen met dezelfde naam kunnen elkaar niet verdringen. Je waarneming klopte alleen niet je verklaring, en dat is precies de nuttige helft. Er is nog één andere weg naar dezelfde melding, die deze reparatie niet dekt: wie zelf `<script>` of `<iframe>` in een vrije-Markdown-dia typt, krijgt hem ook — de veiligheidsscan weigert dan de teruglezing, terecht, maar de melding zegt niet waarom. Dat wordt een eigen issue. Zit je in de v0.5.0-release. Dank voor de melding; je staat in de CHANGELOG. Wil je ook in CONTRIBUTORS.md, laat dan even weten onder welke naam — die vul ik niet zelf in.

brenno

2026-09-01 11:38:13 +00:00

closed this issue
removed the
in-progress
label

kwoot commented

2026-09-01 12:00:01 +00:00

Author

@brenno wrote in #1909 (comment):

Eén vraag, om zeker te weten dat ik jouw geval te pakken heb en niet alleen een geval dat er hetzelfde uitziet: had de presentatie die je opsloeg al inhoud (een titel, opsommingstekens), of was hij nog leeg?

Was inderdaad nog een lege presentatie.

@brenno wrote in https://pawprint.vigilis.online/LibreKAT/Ocideck/issues/1909#issuecomment-15376: > Eén vraag, om zeker te weten dat ik jouw geval te pakken heb en niet alleen een geval dat er hetzelfde uitziet: had de presentatie die je opsloeg al inhoud (een titel, opsommingstekens), of was hij nog leeg? Was inderdaad nog een lege presentatie.

kwoot commented

2026-09-01 12:01:29 +00:00

Author

@brenno wrote in #1909 (comment):

Zit je in de v0.5.0-release. Dank voor de melding; je staat in de CHANGELOG. Wil je ook in CONTRIBUTORS.md, laat dan even weten onder welke naam — die vul ik niet zelf in.

Tuurlijk wil ik ook in de CONTRIBUTORS! :-). Jeroen "Kwoot" Baten dan bijvoorbeeld. Of jeroen@libreplan.dev, dat kan natuurlijk ook.

@brenno wrote in https://pawprint.vigilis.online/LibreKAT/Ocideck/issues/1909#issuecomment-15389: > Zit je in de v0.5.0-release. Dank voor de melding; je staat in de CHANGELOG. Wil je ook in CONTRIBUTORS.md, laat dan even weten onder welke naam — die vul ik niet zelf in. Tuurlijk wil ik ook in de CONTRIBUTORS! :-). Jeroen "Kwoot" Baten dan bijvoorbeeld. Of jeroen@libreplan.dev, dat kan natuurlijk ook.

Rows
Columns

[Bug] Error message when saving #1909