I assume I am not the first person to notice this, but I have found that (somewhat obviously I guess) when a pipeline has a module which unzips e.g. a VCF for some reason (perhaps a tool needs an uncompressed version) it is a destructive process - that is the original gzipped file is not left in-place. AFAICT I haven’t had any issues due to this, but I can foresee plenty of cases where that wouldn’t be true. Is there an argument that we should be adding e.g.

-k

as hardcoded options in modules, or is this simply a risk that everyone else already knew about and was passing

-k

in

ext.args

by default anyway?

Or could we stage in the input via copy instead of link?

Definitely also possible - and obviously this is what happens when workDir is eg S3 right?

I would assume so indeed

If I temporary need to unzip an input file I would always do a redirect -

zcat $file > tmp.ext

or similar. A module should never touch the symlinked file or work dir.

Well, for example this is not the default for

tabix/bgzip

or the conditional decompression step of

jasminesv

. I can't rule out other modules this might happen in either (I'd need to do at least a simple sweep for calls to

bgzip

and then see if they are decompressing to be sure) but I suspect that these may not be the only ones