`filewriter`: file archiving

Bắt đầu bằng cách lập bản đồ filewriter và các hook lưu trữ khả dĩ của nó, bao gồm wrdn, đối chiếu với kho lưu trữ ISIS hiện có và định hướng data-pipeline của EPAC. Điều tra xem dữ liệu có đi qua khu vực NDX của instrument hay không và những consumer nào phụ thuộc vào nó, bao gồm IDAAAAAS, Mantid và AutoReduction. Công việc được xem là hoàn tất khi đã thống nhất được một đường đi có thể khôi phục từ các byte .nxs được tạo ra, qua việc xử lý checksum và archive, đến data gateway và kho lưu trữ băng dài hạn.

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?