A configuração do sinalizador de executável em um script de instalação pode levar à falha de verificação de CRC?

0

Recenty Instalei o VMWare Workstation para Linux na minha máquina Ubuntu e, no processo de instalação, encontrei um problema peculiar. O próprio instalador é um tipo de arquivo que é empacotado com um makefile. Este makefile instala todos os componentes necessários e, a julgar pelos logs, compila alguns módulos e verifica o CRC dos arquivos copiados.

Este instalador deve ser executado assim:

sudo sh ./VMware-Workstation-Full-9.0.1-894247.x86_64.bundle

Mas eu fiz da outra maneira na primeira vez:

chmod uga+x VMware-Workstation-Full-9.0.1-894247.x86_64.bundle
sudo ./VMware-Workstation-Full-9.0.1-894247.x86_64.bundle

Depois disso, a instalação falhou, com as seguintes mensagens:

[2012-12-06 15:07:18,348] [vmware-tools-windows 9.2.2] Failed to copy file from windows.iso to /usr/lib/vmware/isoimages/windows.iso
Traceback (most recent call last):
  File "/tmp/vmis.KNkJ7S/install/vmware-installer/vmis/core/component.py", line 193, in doit
    data = fileobj.read(10485760) # Read 10 MB at once.  Not too large to fill
  File "/tmp/vmis.KNkJ7S/install/vmware-installer/python/lib/gzip.py", line 227, in read
    self._read(readsize)
  File "/tmp/vmis.KNkJ7S/install/vmware-installer/python/lib/gzip.py", line 292, in _read
    self._read_eof()
  File "/tmp/vmis.KNkJ7S/install/vmware-installer/python/lib/gzip.py", line 311, in _read_eof
    raise IOError, "CRC check failed"
IOError: CRC check failed
[2012-12-06 15:07:18,365] [vmware-tools-windows 9.2.2] Installation failed, rolling back installation.

Eu pensei que isso pode ser porque o arquivo baixado foi corrompido, porque suas somas de verificação usando MD5 e SHA1 foram diferentes daquelas fornecidas no site de download. Depois de excluir o arquivo, fazer o download novamente e executá-lo da maneira que deveria ser executado, tudo correu bem.

Então, minha pergunta é puramente por curiosidade aqui. Poderia ter sido que configurar o sinalizador de executável no arquivo levou à falha na verificação de CRC?

    
por Igor Zinov'yev 06.12.2012 / 13:56

1 resposta

1

Não, quando você define o sinalizador de executável somente o arquivo inode , que é onde essa informação é armazenada, muda .

O conteúdo do arquivo permanece inalterado, assim como a soma de verificação.

Você diz que a soma de verificação MD5 / SHA1 do seu arquivo e no site é diferente, então sim, o arquivo baixado foi corrompido . O arquivo provavelmente foi baixado apenas parcialmente, o que explicaria por que ele funcionava inicialmente, mas falhava ao descompactar a si mesmo.

(Você pode verificar isso com um experimento simples:

# ls -l /bin/gawk
-rwxr-xr-x 1 root root 267648 Aug 19  2011 /bin/gawk
# sha1sum /bin/gawk
d8fcc0aae41635dedb449523989af47f290fe22a  /bin/gawk

O modo é 755, a soma de verificação é d8fcc0aae41635dedb449523989af47f290fe22a .

# stat /bin/gawk
(...)
Change: 2012-11-07 17:24:49.000000000 +0100

stat Change mostra que o inode foi alterado pela última vez há um mês.

Agora mudo o modo de arquivo:

# date
Thu Dec  6 16:07:48 CET 2012
# chmod 644 /bin/gawk
# sha1sum /bin/gawk
d8fcc0aae41635dedb449523989af47f290fe22a  /bin/gawk
# stat /bin/gawk
(...)
Change: 2012-12-06 16:07:48.000000000 +0100

O inode foi alterado (compare com a saída de date ), mas a soma de verificação não.)

    
por 06.12.2012 / 16:21