ZimaOS 1.6.2 a généré au moins deux symptômes très différents dans Fichiers, qui ne doivent pas être diagnostiqués comme un seul bug. L’un était une régression reproductible du déplacement : le contenu était déplacé, mais un dossier source vide restait en place. L’autre concernait des erreurs de montage et d’autorisation de lecteurs cloud qui, dans un cas vérifié, ont disparu après un rechargement forcé du navigateur.
La régression liée au déplacement de dossiers comporte une limite importante concernant la version actuelle : ZimaOS 1.7.1 a explicitement corrigé le problème des dossiers vides après une opération de couper. Si vous utilisez une version stable récente et que vous observez toujours le même symptôme, vérifiez d’abord la version exacte avant d’appliquer d’anciennes solutions de contournement propres à la version 1.6.2.
Problème 1 : des dossiers sources vides restent après un déplacement
Le comportement signalé était particulièrement précis : les fichiers et sous-dossiers étaient correctement déplacés entre deux disques SATA internes au format ext4, mais le dossier de premier niveau d’origine restait sur place, vide. Les opérations de copie ne présentaient pas ce problème, et le comportement est apparu après la mise à jour vers la version 1.6.2.
Comment confirmer que vous rencontrez le même bug
- Créez un petit dossier de test contenant un sous-dossier et quelques fichiers.
- Déplacez-le entre deux emplacements de stockage locaux à l’aide de l’application Fichiers de ZimaOS.
- Vérifiez que tout le contenu arrive à destination.
- Vérifiez si seul le dossier parent vide reste à l’emplacement source.
Si des fichiers manquent, si les autorisations changent ou si la destination est un partage réseau plutôt qu’un stockage ext4 local, vous êtes confronté à un autre problème et ne devez pas supposer que cette régression historique en est la cause.
La régression du déplacement de dossiers a été corrigée dans ZimaOS 1.7.1
Les notes de version de ZimaOS 1.7.1 mentionnent explicitement une correction concernant les dossiers vides qui restaient après avoir coupé des dossiers dans certains scénarios.
La meilleure solution pour un système encore sous 1.6.2 consiste donc à effectuer une mise à jour vers une version stable récente après avoir réalisé une sauvegarde, plutôt qu’à créer des scripts qui suppriment automatiquement les dossiers résiduels.
Problème 2 : le lecteur cloud indique que le stockage n’est pas monté ou affiche des erreurs d’instance
Les erreurs liées aux lecteurs cloud peuvent survenir à plusieurs niveaux : l’autorisation auprès du fournisseur cloud, le jeton enregistré par ZimaOS, le montage du backend ou l’état de l’interface web. Les captures ci-dessus semblent graves, mais un utilisateur du fil d’annonce a rétabli le fonctionnement en effectuant un rechargement forcé, comme le suggérait IceWhale.
Étape 1 : effectuez un rechargement forcé de la page ZimaOS
Un simple rechargement peut réutiliser du code JavaScript obsolète et des données de session mises en cache. Utilisez la méthode de rechargement forcé de votre navigateur, puis rouvrez Fichiers et vérifiez si le compte cloud apparaît toujours dans la liste.
Étape 2 : vérifiez si le fournisseur est actuellement pris en charge
Le guide actuel des lecteurs cloud de ZimaOS décrit l’intégration directe dans Fichiers pour Google Drive, Dropbox et OneDrive, l’interface actuelle affichant les fournisseurs pris en charge.
Étape 3 : réautorisez le compte uniquement si la session est réellement défaillante
Si le lecteur reste indisponible après un rechargement forcé, supprimez le compte puis reconnectez-le uniquement après avoir vérifié que vous comprenez quelles tâches locales dépendent de ce montage. La réautorisation ne doit pas être la première réaction face à un simple problème d’affichage.
Comment distinguer un problème de cache de l’interface d’un véritable problème de montage
Un problème d’interface change généralement après un rechargement forcé, avec un autre navigateur ou dans une nouvelle session privée. Un problème de montage du backend persiste d’un navigateur à l’autre et peut également affecter les tâches de sauvegarde ou les chemins d’application qui utilisent le montage cloud.
Faites cette distinction avant de supprimer les identifiants. Si Fichiers semble défaillant dans un navigateur mais fonctionne dans un autre, concentrez-vous sur la session frontend. Si tous les clients et services voient le même stockage manquant, examinez la couche de montage ou d’autorisation.
Ne mélangez pas les bugs de déplacement de fichiers locaux avec les erreurs d’authentification cloud
L’annonce de la version 1.6.2 regroupait de nombreux rapports de mise à niveau sans lien entre eux. Il est facile de transformer ce fil en un article vague sur les « bugs de stockage », mais cela complique le dépannage. Le comportement de couper sur ext4 local et les erreurs OAuth ou de montage cloud reposent sur des éléments de preuve, des points de défaillance et des corrections différents.
La présentation de l’intégration cloud fournit davantage de contexte sur les procédures cloud et locales.
Que faire si le problème persiste sur la version actuelle de ZimaOS
Pour le problème de dossier, notez la version actuelle de ZimaOS, le système de fichiers source et destination, indiquez s’ils sont tous deux locaux et précisez s’il s’agissait d’une opération de couper/déplacer ou de copier. Pour le problème cloud, indiquez le fournisseur, le navigateur, le message d’erreur exact, précisez si un rechargement forcé le modifie et indiquez si le lecteur fonctionne depuis un autre client.
Ces informations permettent de créer un nouveau rapport de bug utile, plutôt que de supposer qu’un ancien défaut de la version 1.6.2 est réapparu.
FAQ
ZimaOS 1.7.1 corrige-t-il le problème du dossier vide restant après le déplacement de fichiers ?
Oui. Les notes de version de la version 1.7.1 mentionnent explicitement la correction des dossiers vides qui pouvaient rester après avoir coupé des dossiers dans certains scénarios.
Dois-je supprimer manuellement les dossiers vides sous 1.6.2 ?
Vous pouvez supprimer les dossiers résiduels dont vous avez confirmé qu’ils sont vides, mais la mise à niveau constitue une meilleure solution à long terme. N’automatisez pas leur suppression avant d’avoir vérifié qu’aucun fichier n’a échoué lors du déplacement.
Pourquoi un rechargement forcé peut-il corriger une erreur de lecteur cloud ?
Le navigateur peut conserver un état frontend ou des données de session obsolètes après une mise à niveau. Si le montage du backend fonctionne correctement, le rechargement des ressources frontend et de la session peut rétablir l’interface sans modifier le compte.
Dois-je immédiatement déconnecter puis reconnecter OneDrive ou Google Drive ?
Non. Essayez d’abord un rechargement forcé et une nouvelle session propre dans le navigateur. Ne réautorisez le compte que lorsque le montage ou le jeton est réellement invalide.
