A fonte começou com uma teoria plausível de dados AppData obsoletos, mas a publicação final torna essa explicação insuficiente. As aplicações que tinham sido removidas anteriormente ignoravam o formulário de configuração e tentavam reutilizar caminhos de montagem inexistentes, produzindo erros do Docker como bind source path does not exist. Uma resposta da comunidade sugeriu remover ou mudar o nome da pasta AppData antiga para que o ZimaOS tratasse a aplicação como nova.
O autor original indicou então que isto tinha funcionado uma vez, mas já não ajudava. Mais importante ainda, as aplicações novas, instaladas pela primeira vez, também começaram a ignorar o formulário de definições e a ficar bloqueadas nos 100%, enquanto a instalação de aplicações através de YAML continuava a funcionar. Isto desloca a suspeita principal de uma pasta de aplicação danificada para o próprio percurso histórico da interface/configuração da App Store.
O Erro do Docker Era Real, Mas Secundário
A falha visível tinha o seguinte aspeto:
Error response from daemon:
invalid mount config for type "bind":
bind source path does not exist: [EXPECTED PATH]O Docker estava corretamente a rejeitar uma montagem de ligação cujo diretório de origem no anfitrião não existia. A questão sem resposta era por que motivo a App Store gerava/reutilizava esse caminho sem apresentar o formulário de definições que normalmente permite ao utilizador escolhê-lo/criá-lo.
Os Dados AppData Obsoletos Eram uma Hipótese da Comunidade
gelbuilding sugeriu eliminar ou mudar o nome de /DATA/AppData/<app-name> para que a loja tratasse a instalação como nova. Outro membro da comunidade afirmou ter utilizado a mesma técnica.
Isso não foi um diagnóstico da equipa da IceWhale, e o teste posterior do autor original demonstrou que não era suficiente para resolver a falha mais abrangente.
O Facto de as Aplicações Instaladas pela Primeira Vez Também Ignorarem o Formulário Altera o Diagnóstico
Quando aplicações novas, sem dados AppData locais anteriores, também começaram a ignorar a configuração, continuar a eliminar repetidamente pastas antigas deixou de ser um ciclo de resolução adequado. O utilizador afirmou explicitamente que reiniciar + eliminar a pasta + reinstalar produzia o mesmo cenário.
O Funcionamento da Instalação por YAML Era uma Evidência Importante
O utilizador afirmou que as aplicações continuavam a poder ser instaladas a partir de YAML. Isto sugere que o Docker não estava completamente avariado e restringe a origem histórica do problema ao fluxo de definição/configuração/apresentação das aplicações da loja.
O ZimaOS 1.7 Reconstruiu a Arquitetura da App Store
O ZimaOS 1.7.0 introduziu a App Store 2.0, com uma interface de descoberta/gestão redesenhada e edição/análise nativas de YAML. O ZimaOS 1.7.1 acrescentou depois mais correções relacionadas com Docker, AppData, WebUI e YAML.
Consulte a referência atual da App Store 2.0.
Ordem Atual de Diagnóstico
- atualize para a versão estável atual do ZimaOS;
- teste uma aplicação simples/oficial que nunca tenha sido instalada;
- registe o caminho exato de montagem no anfitrião que está em falta;
- confirme se a pasta existe e a que armazenamento pertence;
- verifique se a instalação por YAML é bem-sucedida utilizando o mesmo caminho pretendido;
- recolha os registos da App Store/do contentor se o formulário de definições continuar a falhar.
Não Elimine Dados AppData de Forma Impulsiva em Aplicações com Estado
Uma pasta AppData pode conter bases de dados, configuração, chaves, bibliotecas e o estado do utilizador. Mudar o nome é mais seguro do que eliminar durante os testes, e os dados importantes devem ser salvaguardados previamente.
Perguntas Frequentes sobre o Formulário de Definições em Falta
A eliminação dos dados AppData antigos resolveu permanentemente o problema original?
Não. O autor original afirmou que ajudou uma vez, mas posteriormente deixou de funcionar.
As aplicações instaladas pela primeira vez também foram afetadas?
Sim. A publicação final da fonte afirma que as aplicações novas também ignoravam o formulário de configuração e ficavam bloqueadas.
A instalação por YAML continuava a funcionar?
Sim. Essa foi uma das pistas mais fortes de que a falha histórica estava associada ao percurso da App Store, e não a uma indisponibilidade completa do Docker.
