1. Like the picture shown below, --custom_binding local_path:container_path means these two directories to bind.
But don't you need permission to create a directory under /? I'm curious why is there no problem.
You mean how
/case1_working is created inside the Docker container? The image you're using is configured so that the root directory in the built container is writable. The path on your machine (
/media/12T/ABIDE/CASE1/working) is not an immediate child of
/, so there's no issue there.
2. Now, I know why current working directory is read-only.
But, /media/12T/ABIDE/CASE1_copy directory is read-only, how can subdirectories like /media/12T/ABIDE/CASE1_copy/case1_output and /media/12T/ABIDE/CASE1_copy/working be created under it? (before binding)
cpac creates any local paths you specify for binding before creating the container and trying to bind them. So first
cpac looks for all the local paths, creates any that don't exist, then binds them to the specified in-container paths. In that screenshot
/media/12T/ABIDE/CASE1_copy is read-only in the container, but the read-write subdirectories are created before binding anything, so they can be read-write in the container inside a read-only directory (in the container, you wouldn't be able to modify or add to
/media/12T/ABIDE/CASE1_copy, but you could modify or add to
/media/12T/ABIDE/CASE1_copy/case1_output,
/media/12T/ABIDE/CASE1_copy/working,
/tmp,
/logs, and
/output which are all bound to subdirectories of
/media/12T/ABIDE/CASE1_copy on your machine).
3. I changed pipeline_setup['working_directory']['path'] from /tmp to /media/12T/ABIDE/CASE3/working like the underline shown below and bound with /media/12T/ABIDE/CASE3/working(local) using
--working_dir.
But Why is /tmp suddenly bound? (I replaced /tmp → /media/12T/ABIDE/CASE3/working and /tmp is never specified anywhere.)
This is a small bug that shouldn't really affect anything.
cpac currently loads the default pipeline before binding, and the default pipeline includes the path
/tmp as the working directory. Since you're specifying a different working directory, C-PAC shouldn't do anything in /tmp, so you'll just have an extra pointer inside your container while it runs. I wrote a fix for the bug while I was figuring this one out, so the issue should be resolved in the next release of cpac.
4. In this figure, is the /media/12T/practice is read-write and the /media, /media/12T directories are read-only? So the permission was denied?
That's a bug! It looks like the
utils data_config build command writes to
outputSubjectListLocation from
DATA_SETTINGS_FILE (
Usage: cpac utils data_config build [OPTIONS] DATA_SETTINGS_FILE), but
cpac isn't automatically binding that directory. In this example,
/media/12T in your container doesn't point to anywhere, so you can't write to that path (
/media/12T/practice in your container points to
/media/12T/practice locally, but the parent directories aren't accessible from the container). As a stopgap until the issue is resolved, you could pass the
outputSubjectListLocation directory as a custom binding or as the working directory, or run from the
outputSubjectListLocation directory.
5. There is something to check about the container's working directory role.
Working Directory: Directory where CPAC should store temporary and intermediate files.
Are the tasks during pre-processing stored in container's working directory and moved to the bound local through the bind path?
As you noted, the working directory is where temporary and intermediate files are stored. This directory may or may not be bound locally, depending on your configuration and runtime settings. Only the outputs in
cpac_outputs.tsv are copied to the output directory with a BIDS (or nearly BIDS) filename and a JSON sidecar. C-PAC v1.8.4 will include an "expected_outputs.yml" in each participant log directory outlining which outputs to expect your data + pipeline to generate.
The bindings are pointers, so there's no movement involved between the output directory in the container and the bound local path; those paths are addresses to the same location from the container and the local environment respectively.
Thanks again for bringing your concerns to our attention. Both of the bugs mentioned here had not been caught yet as far as I know.