Allow different file modes to be created

[mbr-phys]

This adds a global fileDirMode parameter controlling the permissions requested for directories created by Hadrons output helpers.
This allows projects to create group-writable Hadrons output directories, e.g. 0775, directly at point of creation to avoid manually changing file permissions after the fact when multiple people are running production.

Previously, Hadrons::mkdir() always requested 0755, so directories created by makeFileDir() could not become group-writable even when jobs were submitted with e.g. umask 002. The new parameter defaults to 755, but can be set in the global XML parameters block, e.g.:

<fileDirMode>775</fileDirMode>

The value is parsed as an octal Unix permission mode and validated before being used. Missing or empty values fall back to 755.

Changes

• Added global Hadrons::fileDirMode, defaulting to 0755.
• Added Hadrons::setFileDirMode() to parse and validate octal mode strings.
• Changed recursive Hadrons::mkdir() to use fileDirMode instead of hard-coded 0755.
• Added fileDirMode to Application::GlobalPar.
• Applied the parsed setting in Application::setPar().
• Documented the parameter in application-template/par-example.xml.

[aportelli]

Hi @mbr-phys , thanks but I am not sure I am generally keen on this one. I would at least require an implementation that does not depend on a global variable. Another issue is that you will not necessary get what you asked for, as this will be overridden by the process umask and the parent folder's ACL.

So in short, although it is well motivated, it would be much less fragile to deal with this through the job environment.

However: the job environment can only restrict permissions, not add them, so one can easily argue that Hadrons using 755 by default is too restrictive. So:

• I would be okay with a much simpler PR just changing Hadrons' default to 775
• I would be okay with a PR using the new std::filesystem::create_directory that have a default call with no mode, since Hadrons/Grid are now C++17 compliant, this is more elegant but would need more testing

[aportelli]

See PR chat