Problemas com arquivos (mp4) Linux vs. Windows

Olá, pessoal! Preciso de uma ajuda com este problema.
Meu PC está com Mint 19.2 e meu sistema de arquivos é EXT4. Tenho um arquivo de vídeo em formato mp4 de uns 2.2GB que está rodando sem problemas.
Peguei um pendrive USB 3.0 de 32GB novo e formatei em NFTS via Nemo. Gravei o arquivo mp4 no pendrive usando diferentes procedimentos: via Nemo (gráfico) via terminal com “cp” e via “rsync”. Em todos os casos chequei via terminal com o comando “diff -s” e estava tudo ok.
Quando eu tento executar em um computador com Windows 10, ou direto direto em uma TV com entrada USB e capacidade de tocar mp4, o vídeo trava em partes aleatórias e parece ter sido corrompido.
Colocando o pendrive de volta no linux e executando o comando “diff” novamente ele indica que os binários não são mais iguais…
Eu não sei o que está ocorrendo… já tive problemas outras vezes de máquinas com Windows acusando problemas em pendrives formatados no linux. E agora, parece que o arquivo foi danificado ao tentar abrir no Windows (mas deu o mesmo problema tocando direto na TV).

Aí vem uma pergunta bem noob mesmo: quando eu gravo os arquivos desta forma, formatando o pendrive no Mint em NFTS, gravando o arquivo (seja qual forma, gráfico ou terminal) que estava no meu HD em EXT4 no pendrive, é esperado que dê algum problema (na conversão de sistema de arquivos) quando for ler no Windows?

Adicionalmente: manipular arquivos feitos no Windows, em HD formato NFTS, usando um computador com Linux pode danificar o arquivo, fazendo com que o Windows não o reconheça depois? Minha dúvida é porque tenho HDs de backup de arquivos, gerados no Windows 10 e, agora que troquei de sistema, tenho manipulado estes arquivos. Fiquei com receio (nem testei ainda) que ao usar o Windows, por qualquer razão, estes arquivos possam dar algum problema…

Agradeço a ajuda de vocês!

Já tentou formatar em EXFAT? Qual aplicativo de player você está usando?

Se vai usar na tv, recomendo usar fat32. Mas como vc tem máquina com windows, uma alternativa seria formatar esse pendrive como ntfs usando o windows, dai vc poderia testar se os arquivos continuam com falhas. Eu faria esses dois testes com o pendrive. Testar com partição Fat32 e testar com a ntfs formatado a partir do windows.

O sistema de arquivos NTFS do Linux é de código aberto e o do Windows é de código fechado então logo já é de se imaginar que eles não são os mesmos sistemas de arquivos.
O do Windows é desenvolvido pela Microsoft e é fechado.
O do Linux:
$ mkntfs --version
Copyright © 2000-2007 Anton Altaparmakov
Copyright © 2001-2005 Richard Russon
Copyright © 2002-2006 Szabolcs Szakacsits
Copyright © 2005 Erik Sornes
Copyright © 2007 Yura Pakhuchiy
Copyright © 2010-2014 Jean-Pierre Andre
E é código aberto.

Oi, @anon69309558. Não tentei o ExFAT ainda e uso o VLC.

Oi, @aguamole, entendo a questão dos códigos serem abertos ou fechados, mas acho isto meio estranho. Não deveria dar problema de compatibilidade por causa disto senão não haveria forma de arquivos de trabalho circularem entre os sistemas. Li algumas coisas a mais que podem explicar o que está ocorrendo.

Primeiro, corrigindo meu post, o comando certo para checar a diferença de arquivos, neste caso, é o “cmp”.

Eu tentei usar o FAT32, mas o arquivo levava um tempo absurdo para ser copiado a partir de 99% e achei que estava com algum problema e descobri que há uma questão sobre Virtual Memory no kernel (dirty memory, bufferbloat) que é bem explicada neste link:
https://www.dicas-l.com.br/arquivo/linux_virtual_memory_management_e_lentidao_ao_copiar_arquivos_grandes_para_midia_lenta.php

Dá para acompanhar muito bem o andar da cópia com este comando aqui:

watch -n1 grep -e Dirty: /proc/meminfo

Aparentemente (estou testando ainda, depois posto os resultados) se o sistema é NTFS (formato via Linux mesmo), a cópia é mais rápida (a janela de transferência do Nemo fecha rapidinho), mas pelo que li em outras fontes, é possível que o arquivo ainda esteja sendo transferido da RAM para o pendrive (dizem até para esperar um pouco antes de desmontar - ejetar - o pendrive, para não corromper).
Acho que em alguns casos, tive problemas com isto por desmontar o pendrive assim que fechava a janela de status de transferência.

Bom, vou testar mais um pouco. Estou testando com FAT32 agora que entendo o problema… vamos ver no que vai dar.

_______________________________ NOVAS INFOS__________________________

É, testei novamente com o pendrive em FAT32 e usando o comando acima para companhar a memória Dirty, vi que a janela de status de transferência do Nemo fica ativa até que a memória caia para cerca de 300 a 600 Kb, o que leva vários minutos. Dá pra acompanhar o processo, que segundo o artigo citado acima, trata-se de gravar da RAM (buffer) para o dispositivo físico. Rodei o “cmp” no terminal e acusou 0 (arquivos idênticos ente meu PC com linux EXT4 e o pendrive FAT32)
Espetei na máquina com Windows 10, transferi o arquivo para o HD dele (NTFS/Microsoft) e rodei, sem problemas. Mesma coisa rodando direto no pendrive.

Agora, aqui a coisa fica interessante: peguei outro pendrive e formatei em NTFS pelo linux (que mostra via Disks, que o sistema de arquivos é NTFS/exFAT/HPFS…?)
Abri o terminal para acompanhar a Dirty e fiz a cópia do arquivo pelo Nemo e surpresa: a cópia é muito mais rápida (em comparação ao FAT32) e a janela de status fecha em poucos segundos, indicando que o arquivo foi copiado sem problemas.
Só que não é isto que mostra o terminal. Da mesma forma que antes, assim que fechou a janela de status (e o arquivo apareceu no pendrive, inclusive com miniatura atualizada!) levou ainda uns 2 minutos ou mais para a Dirty cair para a faixa dos 300- 600 Kb e estabilizar (indicando que o processo realmente acabou).
Mas a janela de status do Nemo, puff!, já tinha fechado a um bom tempo. E, claro, se estou copiando o arquivo pra usar em outro lugar, “terminou”, desmonto, desplugo e vou usar, certo? #SQN
Testei este pendrive no Windows e rodou de boa o arquivo, tanto depois de copiado localmente quanto direto do pendrive.
Voltei ele no linux e mandei um “cmp”. Deu arquivo idêntico… ou seja, não foi corrompido no Windows.

Agora vejo (especulo), todas as vezes que tive problemas com pendrive vindo com arquivos copiados do Linux, sempre foram com arquivos da ordem de 1 a 4 GB e sistema NTFS e, em muitos casos, com vários arquivos grandes (ISOs ou vídeos) juntos. Imagino que o processo (Virtual Memory) seja ainda mais demorado neste caso; e como a janela de status da cópia fecha e preciso levar o pendrive para outro lugar, eu desmonto e desplugo e puff, a coisa toda se corrompe (aí o Windows reclama inclusive).

É um comportamento inesperado (pra mim), porque o mesmo parece estar ocorrendo quando uso comando de cópia via terminal (cp, rsync). Ele indica que foi copiado, mas a memória Dirty ainda está muito alta. Estranho é o comando de comparação indicar que o arquivo está idêntico se ele ainda nem foi transferido fisicamente por completo (dá pra ver enquanto o comando watch roda em uma janela de terminal à parte).

Fiz um tunning da Dirty usando um tutorial que achei no fórum do Ubuntu, mas não percebi nenhuma mudança.

Sei que no Windows isto ocorre também - às vezes você grava algo no pendrive e quer remover logo e o Windows diz que algum processo “X” está usando o dispositivo e não deixa ejetar. Se tentar forçar ou tirar sem ejetar, acaba com arquivos corrompidos ou com o pendrive com problemas.

Vou marcar o @Dio pra ver se ele tem algo a dizer sobre isto e se minhas experiências e especulações têm fundamento.

T+ e obrigado pelo feedback.

1 Curtida