ZimaOS 1.6.2 gav upphov till minst två mycket olika Files-symtom som inte bör diagnostiseras som ett och samma fel. Det ena var en reproducerbar regression vid flytt, där innehållet flyttades men en tom källmapp blev kvar. Det andra gällde monterings- och auktoriseringsfel för molnenheter som i ett verifierat fall försvann efter en hård webbläsaruppdatering.
Regressionsfelet vid mappflytt har en viktig gräns för aktuell version: ZimaOS 1.7.1 åtgärdade uttryckligen problemet med tomma mappar efter inklistring. Om du kör en aktuell stabil version och fortfarande ser samma symtom bör du först bekräfta den exakta versionen innan du använder gamla lösningar för 1.6.2.
Problem 1: Tomma källmappar blir kvar efter en flytt
Det rapporterade mönstret var ovanligt specifikt: filer och undermappar flyttades korrekt mellan interna ext4-SATA-enheter, men den ursprungliga mappen på toppnivå blev kvar och var tom. Kopieringsåtgärder visade inte problemet, och beteendet började efter uppdateringen till 1.6.2.
Så bekräftar du att du har samma fel
- Skapa en liten testmapp som innehåller en undermapp och några filer.
- Flytta den mellan två lokala lagringsplatser med ZimaOS Files-appen.
- Bekräfta att allt innehåll kommer fram till destinationen.
- Kontrollera om endast den tomma överordnade mappen finns kvar på källan.
Om filer saknas, behörigheter ändras eller destinationen är en nätverksresurs i stället för lokal ext4-lagring, handlar det om en annan sökväg och du bör inte anta att denna historiska regression är orsaken.
Regressionsfelet vid mappflytt åtgärdades i ZimaOS 1.7.1
Versionsinformationen för ZimaOS 1.7.1 listar uttryckligen en åtgärd för tomma mappar som blir kvar efter att mappar klipps ut i vissa situationer.
Det innebär att den bästa lösningen för ett system som fortfarande kör 1.6.2 är att säkerhetskopiera och uppdatera till en aktuell stabil version, inte att skapa skript som automatiskt raderar kvarvarande mappar.
Problem 2: Molnenheten visar att lagringen inte är monterad eller att en instans saknas
Fel med molnenheter kan uppstå på flera nivåer: molnleverantörens auktorisering, ZimaOS sparade token, backendmonteringen eller webbläsarens gränssnittstillstånd. Skärmbilderna ovan ser allvarliga ut, men en användare i diskussionstråden återställde funktionen genom att göra en hård uppdatering, vilket IceWhale föreslog.
Steg 1: Gör en hård uppdatering av ZimaOS-sidan
En vanlig omladdning kan återanvända inaktuellt JavaScript och cachad sessionsdata. Använd webbläsarens metod för hård uppdatering, öppna sedan Files igen och kontrollera om molnkontot fortfarande visas.
Steg 2: Kontrollera om leverantören stöds för närvarande
Den aktuella guiden för molnenheter i ZimaOS beskriver direkt Files-integrering för Google Drive, Dropbox och OneDrive, och det aktuella gränssnittet visar vilka leverantörer som stöds.
Steg 3: Auktorisera på nytt endast om sessionen faktiskt är trasig
Om enheten fortfarande är otillgänglig efter en hård uppdatering kan du ta bort och ansluta kontot igen, men först efter att ha bekräftat att du förstår vilka lokala uppgifter som är beroende av monteringen. Ny auktorisering bör inte vara det första svaret på ett problem som endast gäller visningen.
Så skiljer du ett problem med gränssnittscachen från ett verkligt monteringsproblem
Ett gränssnittsproblem förändras vanligtvis efter en hård uppdatering, i en annan webbläsare eller i en ny privat session. Ett backendproblem med monteringen kvarstår i olika webbläsare och kan även påverka säkerhetskopieringsuppgifter eller programsökvägar som använder molnmonteringen.
Använd denna skillnad innan du raderar inloggningsuppgifter. Om Files ser trasigt ut i en webbläsare men fungerar i en annan bör du fokusera på frontend-sessionen. Om alla klienter och tjänster ser samma lagring som saknad bör du undersöka monterings- eller auktoriseringslagret.
Blanda inte ihop fel vid lokala filflyttar med autentiseringsfel för molnet
Tillkännagivandet för 1.6.2 samlade många orelaterade rapporter efter uppgraderingen. Det är lätt att göra diskussionstråden till en vag artikel om “lagringsfel”, men det försvårar felsökningen. Beteendet vid klippning av lokala ext4-filer och OAuth-/molnmonteringsfel har olika bevis, olika felpunkter och olika lösningar.
Översikten över molnintegration ger ett bredare sammanhang för arbetsflöden med moln och lokal lagring.
Vad du gör om problemet fortfarande finns i aktuell ZimaOS-version
För mappfelet bör du notera aktuell ZimaOS-version, källans och destinationens filsystem, om båda är lokala samt om åtgärden var klipp/flytt eller kopiering. För molnfelet bör du notera leverantör, webbläsare, det exakta felet, om en hård uppdatering förändrar något och om enheten fungerar från en annan klient.
Det gör en ny felrapport användbar i stället för att du antar att ett gammalt fel i 1.6.2 har återkommit.
Vanliga frågor
Åtgärdar ZimaOS 1.7.1 den tomma mapp som blir kvar efter att filer har flyttats?
Ja. Versionsinformationen för 1.7.1 nämner uttryckligen en åtgärd för tomma mappar som kunde bli kvar efter att mappar klippts ut i vissa situationer.
Bör jag radera de tomma mapparna manuellt i 1.6.2?
Du kan ta bort bekräftat tomma rester, men uppgradering är den bättre långsiktiga lösningen. Automatisera inte raderingen förrän du har verifierat att inga filer misslyckades med att flyttas.
Varför kan en hård uppdatering lösa ett fel med en molnenhet?
Webbläsaren kan behålla inaktuellt frontend-tillstånd eller sessionsdata efter en uppgradering. Om backendmonteringen fungerar kan en uppdatering av frontend-resurser och session återställa gränssnittet utan att kontot ändras.
Bör jag koppla från och ansluta OneDrive eller Google Drive igen direkt?
Nej. Prova först en hård uppdatering och en annan ren webbläsarsession. Auktorisera på nytt endast när monteringen eller token faktiskt är ogiltig.
