Conclusão: trate uma barra de progresso bloqueada nos Ficheiros e uma cópia para a cloud falhada como dois problemas distintos
O tópico de 2024 expôs ambos. As transferências do Dropbox podiam realmente parar, enquanto a interface Ficheiros também podia continuar a mostrar uma tarefa antiga cancelada, perder o progresso após uma atualização ou ocultar operações simultâneas. Esta distinção é importante porque atualizar o navegador pode alterar o que vê sem alterar a transferência subjacente, e repetir a cópia pode criar trabalho duplicado.
Comece por classificar o percurso da transferência
Anote a origem e o destino exatos:
- Cloud → armazenamento local do ZimaOS
- Armazenamento local do ZimaOS → cloud
- Pasta local do ZimaOS → outra pasta local
- Cliente SMB → ZimaOS
O suporte atual do ZimaOS para unidades cloud trata o Google Drive, o Dropbox e o OneDrive como fontes montadas que podem mover dados de e para o armazenamento local. O fluxo de trabalho moderno é muito mais abrangente do que a implementação inicial da versão 1.2.x descrita no tópico.
As unidades cloud do ZimaOS constituem a referência atual do produto.
Verifique a capacidade do destino antes de repetir uma cópia grande
df -h
du -sh /media/DESTINATION/TARGETUma transferência da cloud pode falhar a meio quando o destino fica cheio, um disco externo se desliga ou um caminho montado muda. Confirme o espaço livre e a estabilidade do destino antes de presumir que a API do fornecedor está avariada. Se os dados forem importantes, copie-os em vez de os mover até o destino estar verificado.
Para bibliotecas cloud grandes, utilize lotes menores e verifique cada lote
Os relatos originais das versões 1.2.x/1.3.x eram especialmente pouco fiáveis em transferências cloud de grande escala. O ZimaOS atual melhorou este percurso, mas as bibliotecas grandes continuam a ser mais fáceis de validar quando são movidas em lotes lógicos. Copie uma pasta de nível superior, verifique a contagem e o tamanho dos ficheiros e abra alguns ficheiros representativos antes de iniciar a seguinte.
O modelo de carregamento retomável do Google Drive e os padrões de transferência do Dropbox ilustram por que motivo as transferências cloud grandes precisam de operações com estado e que possam ser repetidas.
Não utilize a atualização do navegador como mecanismo de controlo da transferência
No design antigo de Ficheiros, o estado do progresso residia parcialmente na sessão web carregada e podia desaparecer após uma atualização, mesmo enquanto o trabalho no servidor continuava. A interface também mostrava apenas uma operação, mesmo quando várias estavam em execução. Por isso, quando um cartão de progresso parece desatualizado, não cole imediatamente a mesma pasta outra vez. Primeiro, inspecione o destino e aguarde até a atividade do disco e da rede estabilizar.
O cancelamento de uma transferência pode não ser imediato
A IceWhale explicou que o mecanismo de cancelamento antigo podia precisar de terminar o ficheiro atual antes de a tarefa parar efetivamente. Isto significa que “Cancelamento premido” e “processo de backend parado” nem sempre eram estados idênticos. No caso de ficheiros individuais grandes, dê tempo suficiente ao ficheiro ativo para fechar corretamente antes de iniciar uma tarefa de substituição.
O Finder ou SMB podem ser melhores para os metadados do Mac
O autor original acabou por preferir o Finder do Mac ao Ficheiros do ZimaOS porque as etiquetas do Finder e alguns metadados não eram preservados pelo fluxo de cópia através do navegador da forma esperada. Se os metadados do macOS forem importantes, o SMB direto pode ser um percurso de transferência local melhor do que encaminhar a cópia através de uma abstração de navegador/cloud.
A partilha de ficheiros NAS disponibiliza a alternativa para ficheiros locais.
O suporte cloud atual não significa que todos os fornecedores estejam disponíveis
Não deduza o suporte do iCloud ou do Box a partir de imagens de marketing antigas ou pedidos de funcionalidades. Utilize os fornecedores apresentados na interface atual do ZimaOS Cloud Drive e na documentação. Se um fornecedor não estiver disponível, utilize o mecanismo de sincronização/exportação suportado por esse fornecedor ou uma ferramenta de terceiros deliberada, em vez de inventar uma montagem não oficial.
Faça uma cópia de segurança antes de transformar uma migração numa movimentação
Para dados insubstituíveis, a ordem segura é copiar → verificar → fazer uma cópia de segurança → eliminar a origem mais tarde. A cópia de segurança do ZimaOS é uma camada de segurança melhor do que depender de uma única transferência através do navegador. Se estiver a mover dados de aplicações, em vez de ficheiros comuns, utilize a migração de dados do ZimaOS em vez de uma cópia manual através de Ficheiros.
Perguntas frequentes
Por que motivo a barra de progresso dos Ficheiros fica bloqueada?
Um estado obsoleto da interface e uma transferência do backend realmente bloqueada são possibilidades diferentes. Verifique a atividade do destino antes de repetir a mesma cópia.
Posso atualizar o navegador durante uma cópia?
Uma transferência moderna pode continuar, mas a atualização pode remover ou repor as informações de progresso do lado do cliente. Evite utilizar a atualização como forma de controlar a tarefa.
Por que motivo as cópias cloud grandes falham com mais frequência?
As transferências longas expõem limitações do fornecedor, interrupções de rede, situações de disco cheio e problemas na lógica de repetição. Os lotes menores e verificados são mais fáceis de recuperar.
O ZimaOS é compatível com o iCloud Drive?
Não o presuma com base em imagens antigas do produto. Utilize os fornecedores atualmente apresentados nas definições do ZimaOS Cloud Drive e na documentação atual.
Devo utilizar Ficheiros ou SMB num Mac?
Utilize SMB/Finder quando o desempenho local e os metadados do sistema de ficheiros do Mac forem importantes. Utilize Ficheiros quando a funcionalidade de fluxo de trabalho através do navegador/cloud for a que necessita.
