Den här källan anger en tydlig officiell gräns: ZimaOS kan inte på ett tillförlitligt sätt avgöra vilka godtyckliga filer på en NAS som är ”konfiguration”, så rensningen vid avinstallation är medvetet begränsad till appens AppData-område i stället för att ta bort orelaterade lagringssökvägar. LinkLeong sa att data som lagras på andra platser inte skulle påverkas av den rensningsregeln.
Den ursprungliga skribentens mer avgränsade klagomål var att en felkonfigurerad app ibland inte visade det normala flödet för rensning vid avinstallation, vilket gjorde att dess AppData-mapp blev kvar. Därefter testade skribenten igen i ZimaOS 1.3.2-beta2 och bekräftade uttryckligen att mappen togs bort korrekt även med felkonfigurationen. Det är en historisk korrigering som bekräftats av källan.
IceWhale Sa Att AppData Är Gränsen För Rensningen
LinkLeong förklarade att ZimaOS inte kan identifiera alla ”konfigurationsfiler” korrekt på godtyckliga platser. Regeln blev därför att behandla appens AppData-katalog som omfånget för konfigurations- och användardata vid hanterad rensning.
Data på andra platser på NAS-enheten bör granskas manuellt i stället för att automatiskt tas bort som en del av avinstallationen.
Den Här Gränsen Skyddar Delade Medier Och Lagring
En Docker-app kan montera:
- konfiguration och databas under AppData;
- filmer, foton och dokument på en annan lagringspool;
- nedladdningsmappar som delas med andra appar;
- nätverks- eller USB-lagring.
En avinstallationsrutin som rekursivt följde varje mappad sökväg skulle kunna förstöra delat innehåll, så den snävare AppData-regeln är säkrare.
Problemet I Källan Var Kvarlämnad AppData Från En Felaktig Installation
WuzzyFeasel sa att en ny eller felkonfigurerad container som aldrig startade korrekt ibland inte visade rensningsalternativet och lämnade sin AppData-katalog kvar.
Detta kan vara viktigt när en felaktig konfiguration upprepade gånger gör att en ominstallation ärver samma trasiga tillstånd.
Skribenten Bekräftade Att Beteendet Var Åtgärdat I 1.3.2-beta2
Efter förtydligandet testade OP igen och sa att mappen nu togs bort korrekt även med en felkonfigurerad container.
Presentera därför inte symtomet med den kvarlämnade mappen från 2025 som en aktuell känd begränsning i ZimaOS.
Aktuell AppData Är Fortfarande Ett Kritiskt Område För Beständiga Data
Aktuell dokumentation för ZimaOS betonar att App Store-containrar kan tas bort, men att mappade data på värdsystemet inte kan det. Användare kan också granska och ändra lagringssökvägar för appar samt platser för appdata.
Använd den aktuella modellen för applagring i ZimaOS.
Lagra Inte Oersättligt Användarinnehåll I En Mapp Som Du Planerar Att Ta Bort Som AppData
Vissa appar kombinerar konfiguration, databastillstånd, genererade filer och användarinnehåll i samma trädstruktur. Innan du väljer Delete user data bör du granska appens volymmappningar på värdsystemet och säkerhetskopiera allt som inte kan återskapas.
Manuell Rensning Bör Vara Begränsad Och Bygga På Verifierade Uppgifter
Om en gammal AppData-katalog finns kvar efter avinstallationen ska du kontrollera att ingen aktiv container fortfarande monterar den, säkerhetskopiera data du kan behöva och sedan ta bort endast den bekräftade appkatalogen. Ta inte bort hela AppData-roten rekursivt för att åtgärda en enda misslyckad app.
Vanliga Frågor Om Avinstallation Av AppData I ZimaOS
Vad sa IceWhale att avinstallationsrensningen behandlar som konfigurations- och användardata?
Appens AppData-katalog.
Kommer avinstallationsrensningen avsiktligt att ta bort godtyckliga medier som lagras på andra platser?
Enligt förklaringen i källan påverkas data utanför AppData inte automatiskt av den regeln.
Verifierades det senare att problemet med rensning av felkonfigurerade containrar hade åtgärdats?
Ja. Den ursprungliga skribenten bekräftade att det fungerade korrekt i 1.3.2-beta2.
