filestore.retrieve(): chmod() don't make sense

[sascha_silbe]

While fixing #1550, I stumbled over this code again:

        # Try to hard link from the original file to the targetpath. This can
        # fail if the file is in a different filesystem. Do a symlink instead.
        try:
            os.link(file_path, destination_path)
        except OSError, e:
            if e.errno == errno.EXDEV:
                os.symlink(file_path, destination_path)
            else:
                raise

        # Try to make the original file readable. This can fail if the file is
        # in a FAT filesystem.
        try:
            os.chmod(file_path, 0604)
        except OSError, e:
            if e.errno != errno.EPERM:
                raise

I guess the chmod() is supposed to make the file readable to the caller in case we use a symlink instead of a hardlink.
The permissions don't make much sense:
* allow read+write for the owner (data store user) - OK
* no access to the group - ?
* read access to world - overrides group settings

Was it supposed to be 0640 (rw- r-- ---) instead?

Why do we always do the chmod() instead of only when we actually symlink, BTW? A hardlink doesn't share permissions, only data.

Do we support data stores on FAT filesystems at all? AFAICT our optimizer will fail hard (at least in filestore.hard_link_entry()) on those.

[tomeu]

I guess this is from when we had DS in removable devices and we may drop it now.

[sascha_silbe]

I can't imagine what sugar-artwork might have to do with this, so assigning it back to sugar-datastore on the assumption it was a mistake.