I’m trying to run the test_full-profile of Sarek v.3.9.0 and I get

touch: cannot touch 'dbsnp_146.hg38.vcf.gz.tbi': Permission denied

from MUSE_SUMP, because of this touch-command. The file

dbsnp_146.hg38.vcf.gz.tbi

is read-only on our system, and that is how we would like to keep it.

is it staged in as read only into the work dir?

Thanks for fast response, Rikke. In

.command.run

I see

ln -s /ngc/shared/nf_tools/.references-transactions/approved_source/references/igenomes/Homo_sapiens/GATK/GRCh38/Annotation/GATKBundle/dbsnp_146.hg38.vcf.gz.tbi dbsnp_146.hg38.vcf.gz.tbi

and

/ngc/shared/nf_tools/.references-transactions/approved_source/references/igenomes/Homo_sapiens/GATK/GRCh38/Annotation/GATKBundle/dbsnp_146.hg38.vcf.gz.tbi

is read-only on our system.

👍 this makes sense actually. Could you raise a bug please? We added this as workaround because Muse MUST have the tbi index be newer than the vcf and when nextflow is doing any actual staging of the data, the index always ends up with the older time stamp, since it is smaller. @Famke Bäuerle you are also on an hpc, how is it configured on your end? Are you just updateing the original dbsnp's timestamp every time? [ I think this could cause issues with resuming ] or are you staging it onto the node when you run the process?

Sure, I’ll make a little github-issue on this.

Not sure honestly, I never ran into issues but I thought that this is just touching the symlink info?

Under normal circumstances the index (

*.tbi

) is always newer than the base file (VCF in this case, or CRAM/BAM, FASTA, or whatever), since it is derived from the latter. The problem on (some) clusters is that each node has its own clock, and they are not always perfectly in sync, and if the index is made by a node whose clock is a bit slow[er] (or the base file by one that is fast[er]), then it looks like the index is older, even if it isn't. Using

touch

on the index file ensures that it's "new" (unless the node's clock is way behind). The problem with that is obviously read-only files. (Note: If you are the owner, you can still successfully

touch

a file with

r--r--r--

permissions. It's only if the file is not writable to you and owned by someone else [e.g.

root

] that you have this problem.) I see two potential solutions to this: •

touch

the index file always, but prevent it from exiting with an error (

|| true

might do the trick, or temporarily

set +e

(i.e. don't kill the script on error). The potential problem would be a failure to

touch

an older read-only index, and the crash would be delayed. • Check if the index is older than the base file, and only if so, use

touch

. This can still fail on read-only files, but only if the index is older, which it should not be (when you protect your files, check [and if necessary fix] the date first). For the comparison you can use something like

[ "$tbi" -ot "$vcf" ]

in

bash

. I find this more elegant (and it would fail earlier if it does).

I am with Thomas. Option 2 is more explicit I find.

Ok let me adjust the module!

Note for me for later: I think there are other modules that do sth similar, need to double check this

Just had a better idea:

[ "${ref_vcf_tbi}" -ot "${ref_vcf}" ] && touch *-r "${ref_vcf}"* "${ref_vcf_tbi}"

This makes the index the same time as the VCF, not the current time. This makes more sense if the current time is weeks/months/years after the VCF's modification time, and it avoids the problem with a clock that is waaay slow (which could result in the VCF's time being in the future and the "current" time still being too old).