filesystem configurability for DuplicateI

[mtbc]

The description of #100 suggests that subsequent PRs could include configurability for:

• What is linked how or copied.
• Limit increase in disk usage.

Expanding on that, the focus here is on duplicateUnderlyingFiles. It calls getPath which can tell if a file is in Files/, Pixels/, Thumbnails/, ManagedRepository/, lib/scripts/ (throws) or elsewhere (throws). It also calls duplicateFile which currently decides between hard-linking and copying and could conceivably soft-link. One can imagine extending omero::cmd::Duplicate with extra options that:

• Decide for each location (Pixels/, ManagedRepository/, whatever) how to duplicate the underlying files, conceivably with a list of fallback options.
• Limit the total extra bytes written to files, by accumulating the Files.size or OriginalFile.size total whenever copying then throwing to cause rollback if some threshold is exceeded.

For example, one could define enums for FILES, PIXELS, THUMBS, MANAGED and for HARD_LINK, SOFT_LINK, COPY then allow the client to pass a dictionary with the former as keys whose values are lists of the latter, the current default being:

• FILES → [COPY]
• PIXELS → [COPY]
• THUMBS → [COPY]
• MANAGED → [HARD_LINK, COPY]

Also allow passing a disk usage limit such that one gets an exception if COPY adds up to more. That too could usefully be a dictionary keyed on file location.

Server configuration could specify constraints in similar terms for admins and normal users.

[mtbc]

To #100 now pushed itemized disk usage reporting to ease any subsequent enforcement of usage limits.

[joshmoore]

When/if we update the Request for configurability, I assume we could also update the Response for returning size information.

[mtbc]

Could be the response could somehow mirror the form in which the desired configuration is supplied.