Files (symlinks) not found when using regex and `followLinks: false`

[balvisio]

Not completely sure if this is a bug: I am running into an issue when using the option followLinks in the output section and combining it with the regex. Here is the simplest example to showcase the issue. The first example works as expected:

#!/usr/bin/env nextflow
process createMetaFiles {
    output:
    path "link*"

    shell:
    """
    echo "1" > ~/MetaFile1
    ln -s ~/MetaFile1 link1
    """
}
workflow {
    metaFiles = createMetaFiles()
    metaFiles.view { it -> "MetaFiles: $it" }
}

Now if I add followLinks: false it fails. I expect that followLinks: false shouldn't have an effect:

#!/usr/bin/env nextflow
process createMetaFiles {

    output:
    path "link*", followLinks: false

    shell:
    """
    echo "1" > ~/MetaFile1
    ln -s ~/MetaFile1 link1
    """
}

workflow {
    metaFiles = createMetaFiles()
    metaFiles.view { it -> "MetaFiles: $it" }
}

The error is:

Caused by:
  Missing output file(s) `link*` expected by process `createMetaFiles`

Any suggestion would be appreciated.

Note: If no glob is used in the path section, the previous example works fine:

#!/usr/bin/env nextflow
process createMetaFiles {

    output:
    path "link1", followLinks: false

    shell:
    """
    echo "1" > ~/MetaFile1
    ln -s ~/MetaFile1 link1
    """
}

workflow {
    metaFiles = createMetaFiles()
    metaFiles.view { it -> "MetaFiles: $it" }
}

[balvisio]

For further clarity I have created a PR that tries to solve this issue: https://github.com/nextflow-io/nextflow/pull/3100

[balvisio]

@bentsherman Could kindly someone review this issue and its associated PR: https://github.com/nextflow-io/nextflow/pull/3100 ? Thanks a lot!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pditommaso]

I'm sorry for not getting back to you sooner. You are right, the symlink file should be included in the result.

This has been patched by this commit 👉 d63af784