Increased entropy of shmKey to avoid collisions between genomes.

[jeffhussmann]

I recently ran into an issue where trying to --genomeLoad LoadAndKeep a genome would stall with the error message "Another job is still loading the genome, sleeping for 1 min" despite there being no other such job.

It turns out that in some circumstances, loading a genome after a different genome has previously been loaded
can fail due to the different genome directories hashing to the same shmKey. When this kind of collision happens, attempting to load genome B after genome A will never make it out of the while loop below because the comparison will be between the loaded size of genome A and the expected size of genome B:

STAR/source/Genome_genomeLoad.cpp

Line 219 in ffb66fb

while (*shmNG != nGenome) {

In the current code, the shmKey for a file path is calculated using ftok:

STAR/source/Genome.cpp

Line 19 in 51b64d4

shmKey=ftok(pGe.gDir.c_str(),SHM_projectID);

This stackoverflow answer suggests (and my tests confirm) that ftok only uses the lower 16 bits of the inode of the file path. Apparently, for some filesystems, these lower 16 bits have much less than 16 bits of entropy, so that collisions between different index directories are relatively common. Here is a gist for testing this in your own filesystem, and the first lines of output when run on mine showing the problematic collision between /data/indices/hg38/STAR and /data/indices/e_coli/STAR:

$ python find_ftok_collisions.py /data
385876096:
        /data
        /data/indices/hg38
        /data/indices/e_coli
385876097:
        /data/indices/hg38/STAR
        /data/indices/e_coli/STAR
(more output truncated)

To prevent this issue, this pull request changes the shmKey calculation to just use an index directory's st_ino value directly instead of using ftok (which effectively means not throwing away any bits from st_ino but no longer using st_dev and SHM_projectID at all). This should ensure that different genome directories cannot collide.