Instance Filesystem Management

Foundational concepts:

• The File Map is a collection of pairs wherein each pair is a URI and a collection of file operations upon that URI.
• Each package may register at most one operation per unique URI.
• Possible operations include:
  • Creation (Create)
    • Counts as a "Replacement" operation to remove the need for delete/create combinations.
  • Deletion (Delete)
  • Editing (Edit),
  • Editing-with-creation (EditOrCreate)
  • Claiming automatic creation (Claim)
    • For if a mod creates a file automatically, such as a configuration file
    • Counts as a Create-or-edit step
  • A chain of operations is to be repeated from the beginning to recreate the ancestral file version.
• Verification of file presence can be performed, if deemed necessary, through the file map, which determines which files should or should not exist.
  • Claimed and EditOrCreate files may exist (Remove these on purge but not uninstall?).
  • Map entries which do not end in a deletion must exist.
  • Map entries which end in a deletion must not exist.
• Operations should be topologically sorted by dependency and subsorted by operation such that creations are performed before create-or-edits, which are in turn performed before edits, and finally deletions shall occur.
• Operations should either refer to a source of the file (In the case of non-edit creation) by a reproducable means, or assume the previous contents (as in the case of edits). At no point should the contents of an operation be larger in-memory than a few kilobytes, as these are assumed to be immutable, copyable objects.
  • Long story short, operations should contain information on where to obtain the data and what to do with it, not the data itself.
    • This "Where" should be the package name and a path to the particular installation script node which registered this operation.
  • Performance of an operation can manipulate the actual large-scale information through streams.
  • The file map may be persisted, so storing the actual contents of the changes within the operation would be disruptive.
• Operations should store the package name from which they were registered. As only one version of a package may be installed at a time, this can be used to determine the particular version used.

Questions to address in defining the specification:

• Should move operations be supported? Does anything in particular require them?
• How should we represent some files as "configuration" and other files as "content"? This behavior is required by the primary specification in order to facilitate the difference between "uninstall" and "purge" operations, as well as to prevent hard-verification from failing on user-modified configuration files.