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.