Deze bron noemt een nuttige officiële afbakening: ZimaOS kan niet betrouwbaar bepalen welke willekeurige bestanden op een NAS ‘configuratie’ zijn. Daarom is het opschonen bij het verwijderen van een app bewust beperkt tot het gedeelte AppData van de app, in plaats van dat er niet-gerelateerde opslagpaden worden verwijderd. LinkLeong zei dat gegevens die elders waren opgeslagen, niet door die opschoningsregel zouden worden beïnvloed.
De specifiekere klacht van de oorspronkelijke poster was dat een verkeerd geconfigureerde app soms niet de normale opruimworkflow voor het verwijderen van de app toonde, waardoor de AppData-map achterbleef. Daarna testte de poster opnieuw met ZimaOS 1.3.2-beta2 en bevestigde expliciet dat de map correct werd verwijderd, zelfs bij de verkeerde configuratie. Dit is een historisch probleem waarvan de oplossing door de bron wordt bevestigd.
IceWhale zei dat AppData de opschoningsgrens vormt
LinkLeong legde uit dat ZimaOS niet nauwkeurig elke ‘configuratiebestand’ op willekeurige locaties kan identificeren. Daarom werd besloten de AppData-map van de app te beschouwen als het bereik voor configuratie- en gebruikersgegevens bij beheerde opschoning.
Gegevens elders op de NAS moeten handmatig worden gecontroleerd en niet automatisch als onderdeel van het verwijderen van een app worden verwijderd.
Deze afbakening beschermt gedeelde media en opslag
Een Docker-app kan het volgende koppelen:
- configuratie en databases onder AppData;
- films, foto's en documenten op een andere opslagpool;
- downloadmappen die met andere apps worden gedeeld;
- netwerk- of USB-opslag.
Een verwijderingsroutine die elk gekoppeld pad recursief zou volgen, kan gedeelde inhoud vernietigen. Daarom is de beperktere AppData-regel veiliger.
Het probleem in de bron was achtergebleven AppData van een mislukte installatie
WuzzyFeasel zei dat een nieuwe of verkeerd geconfigureerde container die nooit correct was gestart, soms de opschoonoptie niet toonde en de AppData-map achterliet.
Dit kan problematisch zijn wanneer een verkeerde configuratie er herhaaldelijk voor zorgt dat een herinstallatie dezelfde defecte toestand overneemt.
De poster bevestigde dat het probleem in 1.3.2-beta2 was opgelost
Na de verduidelijking testte de OP opnieuw en zei dat de map nu correct werd verwijderd, zelfs bij een verkeerd geconfigureerde container.
Presenteer het symptoom van de achtergebleven map uit 2025 daarom niet als een huidige bekende beperking van ZimaOS.
De huidige AppData blijft een belangrijk gebied voor permanente gegevens
De huidige documentatie van ZimaOS benadrukt dat containers uit de App Store vervangbaar zijn, maar dat gekoppelde hostgegevens dat niet zijn. Gebruikers kunnen bovendien opslagpaden en locaties voor appgegevens bekijken en wijzigen.
Gebruik het huidige opslagmodel voor ZimaOS-apps.
Bewaar geen onvervangbare gebruikersinhoud in een map die je als AppData wilt verwijderen
Sommige toepassingen combineren configuratie, databasestatus, gegenereerde bestanden en gebruikersinhoud in één boomstructuur. Controleer voordat je Gebruikersgegevens verwijderen selecteert de volumekoppelingen van de app op de host en maak een back-up van alles wat niet opnieuw kan worden gegenereerd.
Handmatig opschonen moet beperkt zijn en op bewijs berusten
Als er na het verwijderen van een app een oude AppData-map achterblijft, controleer dan of geen actieve container deze nog koppelt, maak een back-up van alle gegevens die je mogelijk nodig hebt en verwijder vervolgens alleen de bevestigde map van die app. Verwijder niet recursief de volledige AppData-hoofdmap om één mislukte app te herstellen.
Veelgestelde vragen over het verwijderen van AppData in ZimaOS
Wat beschouwt IceWhale volgens de uitleg als configuratie- of gebruikersgegevens bij het opschonen na het verwijderen van een app?
De AppData-map van de app.
Verwijdert de opschoning bij het verwijderen van een app bewust willekeurige media die elders zijn opgeslagen?
Volgens de uitleg in de bron worden gegevens buiten AppData niet automatisch door die regel beïnvloed.
Is later bevestigd dat het opschoonprobleem met verkeerd geconfigureerde containers was opgelost?
Ja. De oorspronkelijke poster bevestigde dat het correct werkte in 1.3.2-beta2.
