ZimaOS 1.6.2 veroorzaakte minstens twee zeer verschillende Files-problemen die niet als één bug moeten worden gediagnosticeerd. Bij het ene ging het om een reproduceerbare regressie bij verplaatsen: de inhoud werd verplaatst, maar er bleef een lege bronmap achter. Het andere betrof fouten met het koppelen en autoriseren van clouddrives die in één geverifieerd geval verdwenen na een harde browservernieuwing.
De regressie bij het verplaatsen van mappen heeft een belangrijke grens met de huidige versie: ZimaOS 1.7.1 heeft het probleem met lege mappen na knippen expliciet opgelost. Als je een huidige stabiele versie gebruikt en nog steeds hetzelfde probleem ziet, controleer dan eerst de exacte versie voordat je oude workarounds voor 1.6.2 toepast.
Probleem 1: Lege bronmappen blijven achter na verplaatsen
Het gemelde patroon was ongewoon specifiek: bestanden en submappen werden succesvol verplaatst tussen interne SATA-schijven met ext4, maar de oorspronkelijke bovenliggende map bleef leeg achter. Bij kopieerbewerkingen deed het probleem zich niet voor, en het gedrag begon na de update naar 1.6.2.
Zo controleer je of je dezelfde bug hebt
- Maak een kleine testmap met één submap en enkele bestanden.
- Verplaats deze tussen twee lokale opslaglocaties met de ZimaOS Files-app.
- Controleer of alle inhoud op de bestemming aankomt.
- Controleer of alleen de lege bovenliggende map op de bronlocatie achterblijft.
Als er bestanden ontbreken, machtigingen veranderen of de bestemming een netwerkshare in plaats van lokale ext4-opslag is, heb je te maken met een ander scenario en moet je er niet van uitgaan dat deze historische regressie de oorzaak is.
De regressie bij het verplaatsen van mappen is opgelost in ZimaOS 1.7.1
De releaseopmerkingen van ZimaOS 1.7.1 vermelden expliciet een oplossing voor lege mappen die in bepaalde scenario's achterbleven na het knippen van mappen.
Voor een systeem dat nog op 1.6.2 draait, is de beste oplossing daarom om na het maken van een back-up bij te werken naar een huidige stabiele release, in plaats van scripts te maken die achtergebleven mappen automatisch verwijderen.
Probleem 2: Clouddrive toont dat opslag niet is gekoppeld of geeft instantie-fouten
Fouten met clouddrives kunnen op verschillende lagen ontstaan: bij de autorisatie van de cloudprovider, het opgeslagen token van ZimaOS, de backend-koppeling of de browserinterface. De bovenstaande schermafbeeldingen zien er ernstig uit, maar één gebruiker in de aankondigingsthread kon het probleem oplossen door een harde vernieuwing uit te voeren, zoals IceWhale adviseerde.
Stap 1: Vernieuw de ZimaOS-pagina hard
Bij normaal opnieuw laden kunnen verouderde JavaScript-bestanden en gegevens uit een eerdere sessie opnieuw worden gebruikt. Gebruik de methode voor hard vernieuwen van je browser, open daarna Files opnieuw en controleer of het cloudaccount nog steeds wordt vermeld.
Stap 2: Controleer of de provider momenteel wordt ondersteund
De actuele handleiding voor clouddrives van ZimaOS beschrijft directe integratie in Files voor Google Drive, Dropbox en OneDrive. De huidige interface toont de ondersteunde providers.
Stap 3: Autoriseer opnieuw alleen als de sessie echt defect is
Als de drive na een harde vernieuwing nog steeds niet beschikbaar is, verwijder en verbind het account dan opnieuw, maar controleer eerst welke lokale taken afhankelijk zijn van die koppeling. Opnieuw autoriseren hoort niet de eerste reactie te zijn op een probleem dat alleen in de weergave voorkomt.
Zo onderscheid je een probleem met de UI-cache van een echt koppelingsprobleem
Een UI-probleem verandert meestal na een harde vernieuwing, in een andere browser of in een nieuwe privésessie. Een probleem met de backend-koppeling blijft bestaan in verschillende browsers en kan ook gevolgen hebben voor back-uptaken of applicatiepaden die de cloudkoppeling gebruiken.
Gebruik dit onderscheid voordat je inloggegevens verwijdert. Als Files in één browser niet goed werkt maar in een andere wel, richt je dan op de frontendsessie. Als elke client en service dezelfde ontbrekende opslag ziet, onderzoek dan de koppelings- of autorisatielaag.
Verwar bugs bij het verplaatsen van lokale bestanden niet met cloudautorisatiefouten
De aankondiging van 1.6.2 verzamelde veel ongerelateerde meldingen na de upgrade. Het is eenvoudig om van die thread een vaag artikel over “opslagbugs” te maken, maar dat maakt probleemoplossing moeilijker. Het knipgedrag bij lokale ext4-opslag en OAuth-/cloudkoppelingsfouten hebben verschillende aanwijzingen, foutpunten en oplossingen.
Het overzicht van cloudintegratie biedt bredere context over workflows voor cloud en lokale opslag.
Wat je moet doen als het probleem nog steeds voorkomt in de huidige ZimaOS-versie
Noteer voor het mapprobleem de huidige ZimaOS-versie, de bestandssystemen van de bron en bestemming, of beide lokaal zijn en of de bewerking knippen/verplaatsen of kopiëren was. Noteer voor het cloudprobleem de provider, browser, exacte foutmelding, of een harde vernieuwing verschil maakt en of de drive vanuit een andere client werkt.
Zo wordt een nieuw bugrapport bruikbaar, in plaats van dat je ervan uitgaat dat een oude fout uit 1.6.2 is teruggekeerd.
Veelgestelde vragen
Lost ZimaOS 1.7.1 het probleem op waarbij een lege map achterblijft na het verplaatsen van bestanden?
Ja. De releaseopmerkingen van 1.7.1 vermelden expliciet dat lege mappen die in bepaalde scenario's na het knippen van mappen konden achterblijven, zijn opgelost.
Moet ik de lege mappen op 1.6.2 handmatig verwijderen?
Je kunt bevestigde lege achterblijvers verwijderen, maar bijwerken is de betere oplossing voor de lange termijn. Automatiseer het verwijderen niet voordat je hebt gecontroleerd dat er geen bestanden niet zijn verplaatst.
Waarom kan een harde vernieuwing een fout met een clouddrive oplossen?
De browser kan na een upgrade verouderde frontendstatus of sessiegegevens bewaren. Als de backend-koppeling goed werkt, kan het vernieuwen van de frontendbestanden en sessie de interface herstellen zonder het account te wijzigen.
Moet ik OneDrive of Google Drive onmiddellijk ontkoppelen en opnieuw verbinden?
Nee. Probeer eerst een harde vernieuwing en een andere schone browsersessie. Autoriseer alleen opnieuw wanneer de koppeling of het token daadwerkelijk ongeldig is.
