Contains configuration data which must be preserved across executions of StrongBox, and therefore is saved to storage. To maintain consistency and since such writes to storage can be time consuming, this class’s interface promotes batching small mutations together cohesively. Also note that StrongBox is (currently) set up so only one thread accesses this data at a time, therefore no access synchronization is attempted.
Bases: StoredConfiguration._StoredConfiguration_NamedTuple
A class wrapper for _StoredConfiguration_NamedTuple. A _StoredConfiguration_NamedTuple contains only the configuration data from a StoredConfiguration object that should actually be saved to storage (e.g. not the encrypter attribute). Using a named tuple allows us to pickle/unpickle and save/load the data with explicit constraints on the order and number of attributes expected. This should help catch potential saving and loading errors as we evolve the StoredConfiguration class and its attribute list.
A convenience function for retrieving a given peer’s revision data for a given store.
A revision is considered greater than another if its signature is valid and either the other’s signature is not, or the other revision is numbered lower.
Update our knowledge of peers based on gossip from another peer.
Attempt to load a previously stored configuration file, instead trying the backup copy if necessary.
Returns: | A StoredConfiguration object or None if neither file could be loaded. |
---|
Record data on a new peer or update existing information on a known peer in our stored configuration data. Also, accordingly make any necessary updates to our recorded store-peer associations.
Delete a file or directory from a locally held store (either the user’s or a backup of another user’s store).
Get the contents of a file (or return None for a directory) in preparation for transmission, decrypting on-the-fly if the item originates from the user’s store.
Save a new directory or file, or update a file within a locally held store (either the user’s own store or the backup of another store).
Update this peer’s already existing IP address data.
After sending a peer synchronization data and verifying their store contents, update our recording of their revision for the store in question to match our own.
Increment the revision number and recalculate the corresponding hash and revision signature for the current state of the user’s store.