O motivo pelo qual você está vendo esse problema é que o padrão curinga muda o comando COPY para o modo de concatenação, que é projetado para arquivos ASCII de texto simples. No modo ASCII, alguns dados em arquivos binários parecem um caractere "End of File".
Arquivos Excel .XLSX são essencialmente arquivos Zip com uma extensão diferente
e arquivos Zip são arquivos binários, não ASCII. O comando COPY está tratando esse arquivo binário como um arquivo ASCII e tentando concatenar o conteúdo com nada.
Pode-se pensar que concatenar um arquivo com nada lhe daria o mesmo arquivo com o qual você começou, mas não neste caso.
O comando COPY continua processando um arquivo apenas até atingir um caracter End of File (EOF) . Quando alcança esse personagem, continua no próximo arquivo. (Neste caso, ele pára completamente o processamento.)
Seus arquivos binários do Excel contêm dados que, quando convertidos em ASCII, representam caracteres EOF e, portanto, a concatenação do arquivo termina antes do esperado.
Para ilustrar isso, usei o comando COPY para concatenar um arquivo 7zip com um arquivo em branco do Excel (acabei de renomeá-los como file_1.xlsx e file_2.xlsx ). Eu abri o arquivo 7zip e o arquivo de saída no Notepad ++ e comparei o conteúdo usando o WinMerge.
Comovocêpodevernaimagem,osdoisarquivossãoidênticosatéocaractere(1A).
Emseguida,concateneidoisarquivosdetextosimples,quefuncionaramperfeitamente.Noentanto,depoisqueinseriessecaractere(1A)(queaparecenoNotepad++como(sub))emumdosarquivosdetexto,confirmeiqueocomandoCOPYparouexatamentenessepontoepassouparaopróximoarquivo.
