filewriter: file archiving #85

The file-writing infrastructure must be able to trigger file-archiving workflows to get the file from wherever it is generated, to places where it can be read by downstream consumers and stored according to the ISIS data policy.

This includes:

• Generating file checksums
  • See comment from @ChrisM-S on ADR to drop .raw files for further details about how file checksumming is currently done
• Marking files with read-only attribute [for existing windows ISIS archive]
• Moving files from the location where they were generated to the archive
  • In the immediate term this is assumed to be the existing ISIS archive, however the chosen approach should be flexible enough to cope with longer-term architectural direction in this area (for example see EPAC 'data pipeline' slides).
  • Including sufficiently robust processes to "catch up" and recover gracefully later if the archive is offline or unreachable at the time a file is generated, or the copy onto the archive fails.
• Any other steps which are required to go from some .nxs bytes on disk, to a file that a user can download from ISIS data gateway, that mantid can read from its expected locations, and gets archived to SCD long-term tape store.

This functionality does not necessarily have to be in the filewriter itself; it may be better to live outside the filewriter process, as long as the filewriter provides adequate 'hooks' for triggering archiving (e.g. wrdn)

Questions

• Do files, or a copy, go via the instrument (NDX) data area at all? Which downstream processes depend on getting data from there - IDAAAAAS, Mantid, AutoReduction, ...?

Potential differences from existing files

• File checksums are currently written into a Windows alternate file stream in the .raw file. This almost certainly is not the best approach for a linux-based filewriter. Do any downstream consumers other than the archival process currently use these checksums embedded in alternate file streams?