`filewriter`: file archiving

首先，将 filewriter 及其可能的归档钩子（包括 wrdn）与现有的 ISIS archive 以及 EPAC data-pipeline 的方向进行映射。调查数据是否会经过 instrument NDX area，以及哪些 consumer 依赖它，包括 IDAAAAAS、Mantid 和 AutoReduction。当从生成的 .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?