Ficheiro corrompido após transferência? Como evitar a perda de dados

A corrupção de ficheiros após transferência é rara nos serviços modernos baseados em HTTPS porque os checksums TCP, a integridade do TLS 1.3 e as tags de autenticação AES-GCM apanham todos os erros de bit em trânsito. Quando a corrupção ocorre, é geralmente nos endpoints: transferência interrompida que gravou um ficheiro parcial, erros de disco durante a escrita, ou um erro no cliente a truncar streams. Verifique com um hash SHA-256 em ambos os lados. Se os hashes coincidirem, o ficheiro é idêntico. Se diferirem, volta a transferir. Os serviços que usam AES-256-GCM fornecem autenticação integrada, pelo que uma desencriptação bem-sucedida é por si só prova de integridade.

Por que as transferências raramente corrompem em trânsito

Cada pedido HTTPS transporta uma verificação de integridade TLS. O TLS 1.3 com cifras AEAD como AES-256-GCM ou ChaCha20-Poly1305 produz uma tag de autenticação por registo; se um bit for alterado durante a transmissão, a verificação da tag falha e o registo é rejeitado antes de chegar à aplicação. O TCP acrescenta o seu próprio checksum de 16 bits por segmento. A probabilidade combinada de uma corrupção silenciosa passar por ambas as verificações é astronomicamente baixa — cerca de 1 em 2^128 apenas para o TLS.

Os protocolos não encriptados (FTP, HTTP simples) são menos robustos. O checksum do TCP falhará nalguns erros; os bits podem ser alterados silenciosamente em hardware intermediário com RAM defeituosa. Esta é uma razão genuína para evitar FTP simples em transferências grandes, para além do problema de exposição de credenciais.

Onde a corrupção realmente acontece

As causas mais comuns de corrupção pós-transferência, por ordem aproximada de frequência:

Transferência interrompida guardada como ficheiro parcial. As transferências no navegador que perdem a ligação a 75% frequentemente guardam um ficheiro 75% completo que parece "presente" na pasta de Transferências mas abre danificado. O Chrome e o Firefox marcam tipicamente estes como .crdownload ou .part, mas versões mais antigas e alguns gestores de terceiros não o fazem.

Erros de escrita no disco local. Um disco externo com falhas, um disco cheio ou um setor danificado faz com que o ficheiro seja escrito parcialmente. O Windows nem sempre reporta isto claramente; o macOS faz-o por vezes.

Quarentena do antivírus a modificar o ficheiro. O antivírus em tempo real por vezes remove secções executáveis ou modifica arquivos a meio da transferência para os "desinfetar", deixando o ficheiro tecnicamente presente mas logicamente corrompido.

Erro do cliente a truncar streams. Raro em clientes bem mantidos, mas alguns clientes FTP legados, versões antigas do SyncToy ou scripts de carregamento personalizados têm erros conhecidos de truncamento.

Verifique com hashes SHA-256

A única forma fiável de provar que um ficheiro foi transferido intacto é calcular um hash criptográfico em ambos os lados e comparar. O SHA-256 é universal, rápido (500 MB/s em CPUs modernas com AES-NI) e resistente a colisões.

macOS/Linux: shasum -a 256 ficheiro.mov. Windows 10+: certutil -hashfile ficheiro.mov SHA256. Ambos produzem uma string hexadecimal de 64 caracteres. Envie o hash juntamente com o link ("SHA256: a1b2c3...") para que o destinatário possa verificar após a transferência.

Se os hashes coincidirem, o ficheiro é bit a bit idêntico. Se diferirem, volta a transferir.

O AES-GCM oferece integridade sem custos adicionais

Os serviços que encriptam com AES-256-GCM (encriptação autenticada com dados associados) incluem uma tag de autenticação em cada bloco. Quando o destinatário desencripta, uma falha na verificação da tag significa que o texto cifrado foi adulterado ou corrompido, e a desencriptação falha de forma explícita com um erro como "GCM authentication failed".

Isto significa que se um ficheiro for desencriptado com sucesso, está garantidamente inalterado. Não é necessária uma verificação SHA-256 separada do lado do destinatário. O HexaTransfer, o modo Seguro da Smash, o SwissTransfer, o Tresorit Send e o Proton Drive usam todos AES-GCM ou XChaCha20-Poly1305 (modo autenticado semelhante) exatamente por esta razão.

Detetar transferências parciais

Um sinal claro de uma transferência parcial: o tamanho do ficheiro em disco é menor do que o anunciado na página de transferência. Clique com o botão direito no ficheiro transferido, verifique o tamanho e compare com o tamanho indicado pelo remetente. Se não coincidirem, a transferência não terminou.

Os ficheiros multimédia revelam isto facilmente. Um MP4 parcial reproduz durante um minuto e depois corta. Um ZIP parcial retorna "ficheiro corrompido" na extração. Um PDF parcial mostra as primeiras páginas e depois dá erro. Os ficheiros de texto frequentemente abrem bem mas estão truncados silenciosamente, o que é o pior caso porque não se nota.

Transferências retomáveis para ligações instáveis

Se a ligação do destinatário cair durante a transferência, o suporte a retoma é importante. Os pedidos de intervalo HTTP (RFC 7233) permitem que um cliente reinicie a partir de um offset. O curl trata disto com -C -, o wget com -c. Os gestores de transferência baseados no navegador variam; Firefox e Chrome retomam dentro da mesma sessão se o servidor suportar intervalos.

Os serviços que usam POST simples ou não expõem cabeçalhos Range forçam um reinício completo em caso de interrupção, o que num ficheiro de 10 GB sobre uma ligação móvel de 20 Mbps é problemático.

Interferência do antivírus

O Windows Defender, o Avast, o Bitdefender e o McAfee por vezes intercetam as transferências a meio do stream para as analisar. Geralmente isso é transparente. Ocasionalmente, para formatos de arquivo comprimido ou executáveis, o antivírus decide "limpar" o ficheiro e remove o conteúdo ou substitui o ficheiro por um stub de quarentena.

Se um ficheiro é consistentemente transferido corrompido no dispositivo do destinatário, peça-lhe que desative temporariamente o antivírus em tempo real e tente novamente. Se a segunda tentativa for bem-sucedida, o antivírus é o culpado. Adicione o domínio do serviço de transferência à lista de exclusões do antivírus.

Espaço em disco e problemas no sistema de ficheiros

Uma transferência também pode ser corrompida se o disco de destino ficar cheio a meio da escrita. O macOS escreve através da camada de snapshot do APFS e geralmente reporta os erros de forma clara. O NTFS do Windows tende a truncar silenciosamente. Em discos externos, verifique o espaço livre antes de iniciar uma transferência de 10 GB.

Os erros de sistema de ficheiros são raros mas reais. O exFAT em versões antigas do Windows teve erros de truncamento com ficheiros acima de 4 GB. ext4, NTFS e APFS são fiáveis nas versões atuais do sistema operativo.

Valide com ferramentas específicas para cada formato

Ficheiros de vídeo: ffprobe -v error ficheiro.mp4 reporta erros silenciosamente. Se a saída estiver vazia, a estrutura do contentor está intacta. Para análise mais aprofundada, ffmpeg -v error -i ficheiro.mp4 -f null - percorre cada fotograma e reporta erros de descodificação.

PDFs: o comando "Validate" do Acrobat verifica a estrutura de objetos. qpdf --check ficheiro.pdf faz o mesmo a partir da linha de comandos.

Imagem médica DICOM: dcmdump ficheiro.dcm do DCMTK verifica as tags obrigatórias e a estrutura, o que é importante para sistemas PACS hospitalares que rejeitam ficheiros inválidos.

Arquivos comprimidos: unzip -t ficheiro.zip e 7z t ficheiro.7z testam sem extrair. Rápido e deteta a maioria das corrupções.

Escolha serviços com integridade integrada

Para transferências críticas, escolha um serviço que forneça integridade criptográfica por conceção. Encriptação de ponta a ponta AES-GCM, apresentação de hash SHA-256 na página de transferência, ou validação explícita de checksum no cliente, todos fornecem prova em vez de esperança. O HexaTransfer usa AES-256-GCM, pelo que uma desencriptação bem-sucedida verifica por si mesma que o ficheiro não foi alterado, e o limite de 10 GB por transferência cobre a maioria dos entregáveis profissionais.

Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.