`filewriter`: file archiving

まず、既存の ISIS archive および EPAC data-pipeline の方向性と照らし合わせて、filewriter とそのアーカイブフックの候補（wrdn を含む）を整理します。データが instrument NDX area を通過するかどうか、また IDAAAAAS、Mantid、AutoReduction を含め、どの consumer がそれに依存しているかを調査します。生成された .nxs バイト列から、checksum と archive の処理を経て、data gateway および長期テープストアに至る、合意済みで復旧可能な経路が確立されれば完了です。

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?