Can setting the executable flag on an installation script lead to CRC check failure?

Question

Recenty I have installed the VMWare Workstation for Linux on my Ubuntu machine and in the process of installation I have ran into a peculiar problem. The installer itself is some kind of archive that is bundled with a makefile. This makefile installs all the needed components, and judging by the logs compiles some modules and checks CRC of copied files.

This installer should be run something like this:

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

But I have done it the other way the first time:

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

And after that the installation has failed, with the following messages:

[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.

I had thought that this may be because the downloaded file has been corrupted, because its checksums using MD5 and SHA1 have been different from those provided on the download site. After deleting the file, redownloading it and running it the way it should be run, it all went OK.

So my question is purely out of curiosity here. Could it have been that setting the executable flag on the file has led to the CRC check failing?

Answer 1

No, when you set the executable flag only the file inode, which is where that information is stored, changes.

The file contents remain unmodified, and so does the checksum.

You say the MD5/SHA1 checksum of your file and on the website differed, so yes, the downloaded file was corrupt. The file was probably only partially downloaded, which would explain why it initially worked, but crashed when unpacking itself.

(You can check this yourself with a simple experiment:

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

Mode is 755, checksum is d8fcc0aae41635dedb449523989af47f290fe22a.

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

stat's Change show that the inode was last changed a month ago.

Now I change the file mode:

# 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

The inode has changed (compare with date's output), but checksum hasn't.)