O ZimaOS 1.6.2 provocou pelo menos dois sintomas muito diferentes nos Ficheiros, que não devem ser diagnosticados como um único erro. Um deles era uma regressão reproduzível ao mover ficheiros, em que os conteúdos eram movidos, mas permanecia uma pasta de origem vazia. O outro envolvia erros de montagem e autorização de unidades na nuvem que, num caso verificado, desapareceram após uma atualização forçada do navegador.
A regressão ao mover pastas tem uma fronteira importante na versão atual: o ZimaOS 1.7.1 corrigiu explicitamente o problema das pastas vazias após operações de cortar. Se estiver a executar uma versão estável atual e continuar a ver o mesmo sintoma, confirme primeiro a versão exata antes de aplicar soluções antigas para o 1.6.2.
Problema 1: Permanecem Pastas de Origem Vazias Após uma Operação de Mover
O padrão reportado era particularmente específico: os ficheiros e subpastas eram movidos corretamente entre unidades SATA internas com ext4, mas a pasta de nível superior original permanecia vazia. As operações de cópia não apresentavam o problema, e o comportamento começou após a atualização para a versão 1.6.2.
Como confirmar que tem o mesmo erro
- Crie uma pequena pasta de teste que contenha uma subpasta e alguns ficheiros.
- Mova-a entre duas localizações de armazenamento local utilizando a aplicação Ficheiros do ZimaOS.
- Confirme que todos os conteúdos chegam ao destino.
- Verifique se apenas a pasta principal vazia permanece na origem.
Se faltarem ficheiros, as permissões forem alteradas ou o destino for uma partilha de rede em vez de armazenamento local ext4, está perante um cenário diferente e não deve presumir que esta regressão histórica é a causa.
A Regressão ao Mover Pastas Foi Corrigida no ZimaOS 1.7.1
As notas de lançamento do ZimaOS 1.7.1 indicam explicitamente uma correção para as pastas vazias que permaneciam após cortar pastas em determinados cenários.
Isto significa que a melhor solução para um sistema que ainda esteja na versão 1.6.2 é atualizar para uma versão estável atual depois de efetuar uma cópia de segurança, e não criar scripts que eliminem automaticamente as pastas restantes.
Problema 2: A Unidade na Nuvem Mostra Erros de Armazenamento Não Montado ou de Instância
Os erros das unidades na nuvem podem ocorrer em várias camadas: na autorização do fornecedor de nuvem, no token guardado pelo ZimaOS, na montagem do backend ou no estado da interface do navegador. As capturas de ecrã acima parecem graves, mas um utilizador no tópico do anúncio conseguiu recuperar ao efetuar uma atualização forçada, conforme sugerido pela IceWhale.
Passo 1: Atualize forçadamente a página do ZimaOS
Uma atualização normal pode reutilizar JavaScript desatualizado e dados de sessão em cache. Utilize o método de atualização forçada do navegador, reabra os Ficheiros e verifique se a conta na nuvem continua listada.
Passo 2: Verifique se o fornecedor é atualmente suportado
O atual guia de unidades na nuvem do ZimaOS documenta a integração direta nos Ficheiros com o Google Drive, Dropbox e OneDrive, sendo que a interface atual apresenta os fornecedores suportados.
Passo 3: Volte a autorizar apenas se a sessão estiver realmente danificada
Se a unidade continuar indisponível após uma atualização forçada, remova e volte a ligar a conta apenas depois de confirmar que compreende quais as tarefas locais que dependem dessa montagem. A nova autorização não deve ser a primeira resposta a um problema meramente visual.
Como Distinguir um Problema de Cache da Interface de um Problema de Montagem Real
Um problema da interface costuma alterar-se após uma atualização forçada, noutro navegador ou numa nova sessão privada. Um problema de montagem do backend persiste em diferentes navegadores e pode também afetar tarefas de cópia de segurança ou caminhos de aplicações que utilizem a montagem na nuvem.
Faça essa distinção antes de eliminar credenciais. Se os Ficheiros parecerem danificados num navegador, mas funcionarem noutro, concentre-se na sessão do frontend. Se todos os clientes e serviços virem o mesmo armazenamento em falta, investigue a camada de montagem ou autorização.
Não Misture Erros ao Mover Ficheiros Locais com Erros de Autenticação na Nuvem
O anúncio da versão 1.6.2 reuniu muitos relatos de atualização não relacionados. É fácil transformar esse tópico num artigo vago sobre “erros de armazenamento”, mas isso dificulta a resolução de problemas. O comportamento de cortar em armazenamento local ext4 e os erros de OAuth ou montagem na nuvem têm evidências, pontos de falha e soluções diferentes.
A visão geral da integração na nuvem apresenta o contexto mais abrangente dos fluxos de trabalho na nuvem e locais.
O Que Fazer se o Problema Ainda Existir no ZimaOS Atual
Para o problema das pastas, registe a versão atual do ZimaOS, o sistema de ficheiros da origem e do destino, se ambos são locais e se a operação foi cortar/mover ou copiar. Para o problema da nuvem, registe o fornecedor, o navegador, o erro exato, se uma atualização forçada o altera e se a unidade funciona a partir de outro cliente.
Isto torna útil um novo relatório de erro, em vez de presumir que um erro antigo da versão 1.6.2 regressou.
Perguntas Frequentes
O ZimaOS 1.7.1 corrige a pasta vazia que fica depois de mover ficheiros?
Sim. As notas de lançamento da versão 1.7.1 mencionam explicitamente a correção das pastas vazias que podiam permanecer após cortar pastas em determinados cenários.
Devo eliminar manualmente as pastas vazias na versão 1.6.2?
Pode remover pastas vazias restantes depois de confirmar que estão realmente vazias, mas atualizar é a melhor solução a longo prazo. Não automatize a eliminação até verificar que nenhum ficheiro falhou ao ser movido.
Porque é que uma atualização forçada pode corrigir um erro de uma unidade na nuvem?
O navegador pode manter um estado do frontend ou dados de sessão desatualizados após uma atualização. Se a montagem do backend estiver saudável, atualizar os recursos do frontend e a sessão pode restaurar a interface sem alterar a conta.
Devo desligar e voltar a ligar imediatamente o OneDrive ou o Google Drive?
Não. Experimente primeiro uma atualização forçada e outra sessão limpa do navegador. Volte a autorizar apenas quando a montagem ou o token forem realmente inválidos.
