✅ Deploy Preview for nextflow-docs-staging canceled.

Testing:

#!/usr/bin/env nextflow

params.dir = "$projectDir/test_data"

workflow {
    channel.of(file(params.dir))
        .map { dir -> dir.listFiles() }
        .flatten()
        .view { "Found: ${it.name}" }
}

mkdir -p test_data_real                                                                           
echo "hello" > test_data_real/file.txt                                 
ln -s test_data_real test_data

echo "hello" > file_real.txt 
ln -s file_real.txt test_data/file_link.txt

Nextflow 25.10.3:

>  nextflow run test-symlinks.nf
N E X T F L O W  ~  version 25.10.3
Launching `test-symlinks.nf` [romantic_poitras] DSL2 - revision: dc961e3873
Found: test_data

This branch:

>  make compile && ./launch.sh run test-symlinks.nf
./gradlew compile exportClasspath
<redacted>
DONE Thu Feb  5 10:39:28 GMT 2026

N E X T F L O W  ~  version 25.12.0-edge
Launching `test-symlinks.nf` [pedantic_tuckerman] - revision: dc961e3873
Found: file.txt
Found: file_link.txt

For completion, here's using the new listDirectory():

workflow {
    channel.of(file(params.dir))
        .map { dir -> dir.listDirectory() }
        .flatten()
        .view { "Found: ${it.name}" }
}

Current master:

N E X T F L O W  ~  version 25.12.0-edge
Launching `test-symlinks.nf` [romantic_boyd] - revision: a10ccfe3f8
Found: test_data

This branch:

N E X T F L O W  ~  version 25.12.0-edge
Launching `test-symlinks.nf` [mighty_mcclintock] - revision: a10ccfe3f8
Found: file.txt
Found: file_link.txt

Background Slack thread: https://nfcore.slack.com/archives/CJRH30T6V/p1770242055833159?thread_ts=1770217638.291789&cid=CJRH30T6V

Folks, i've reverted this PR. The change looks harmless at first glance but has a wider blast radius than expected.

Affected production callers

• FilesEx.createLinkImpl — enumerates a directory to create hard links recursively.
• LocalUpdateRepository — lists plugin directories.
• Session.findBinEntries — discovers executable scripts in the pipeline bin/ directory.

Task hash impact

findBinEntries populates the bin entries that are factored into task hashing. If FOLLOW_LINKS changes which files are returned (or how symlinked entries are classified), this silently invalidates cached task results — users would see unexpected cache misses with no explanation.

This is a semantic difference that could introduce bugs both in internal code and in user pipelines calling .listFiles() as a public API. Tho I understand that's a desirable patch, at this point it would be better to provide an option to control it.

Thanks @pditommaso, well spotted.

That's fine, we can just apply this change to listDirectory() since it is new in 26.04

@adamrtalbot please re-submit this PR, making listFiles0 parameterized so that listFiles calls it without follow_links and listDirectory calls it with follow_links.