MRIQC doesn't like relative paths: Can error be thrown right away?

[nicholst]

In my first mriqc run, I found that a relative path failed to work. I.e. with this run:

docker run -it --rm -v BIDS:/data:ro -v BIDSmriqc:/out poldracklab/mriqc:latest /data /out participant 

I got errors

2018-02-13 20:31:15,018 mriqc.cli:WARNING No T1w scans were found in /data
2018-02-13 20:31:15,019 mriqc.cli:WARNING No bold scans were found in /data
2018-02-13 20:31:15,019 mriqc.cli:WARNING No T2w scans were found in /data

BIDS is in fact a just-validated BIDS directory and had T1w and bold files; so I tried

docker run -it --rm -v $PWD/BIDS:/data:ro -v BIDSmriqc:/out poldracklab/mriqc:latest /data /out participant

and it ran. At the end, with the log suggesting all is honky dory, with lines like

2018-02-14 00:07:26,983 niworkflows:INFO Generating visual report
2018-02-14 00:07:43,637 niworkflows:INFO Successfully created report (/usr/local/src/mriqc/work/workflow_enumerator/funcMRIQC/SpatialNormalization/_in_file_..data..sub-03..func..sub-03_task-FacesHappy_bold.nii.gz/EPI2MNI/report.svg)

actually... nothing. There was no BIDSmriqc output folder.

I presume if I re-run (and wait another 9 hours) I may hope for a result if I replace BIDSmriqc with $PWD/BIDSmriqc but it would be really nice if

1. The documentation can be updated, if this is correct, that relative paths cannot be used with docker and,
2. If there was some sort of prospective error to warn me that output is actually going to /dev/null (an error is generated for /data, so can't it be generated for /out?)

Tnx!

[chrisgorgo]

Sorry for this. This is a Docker issue (see moby/moby#4830 (comment)). Not sure we would be able to detect this from within the container, but we should definitely update the documentation.

[nicholst]

I created a PR for the docs to address this #690; this issue could be closed.

[chrisgorgo]

FYI - I checked the --mount option (which gives better errors than -v), but it does not work on Windows.

[oesteban]

Closing after #690 was merged. Thanks @nicholst.