File Management - Hive2Hive/Hive2Hive GitHub Wiki

The file management encapsulates the following operations:

These operations become available for users that have successfully logged in to the network.

Add

With Hive2Hive, files and folders can be added to the network. This means that they get stored in the DHT.

Adding a File

The process for adding a file includes the following steps:

  1. The User Profile is fetched from the DHT.
  2. The File Index is added to the File Tree in the user profile.
  3. The user profile is put back to the DHT.
  4. A new File Encryption Key Pair is created.
  5. The file is split up into multiple File Chunks.
  6. Each file chunk is encrypted with the created File Encryption Public Key.
  7. For each file chunk, a random Location Key is created.
  8. Each file chunk is put to the DHT using its particular location key.
  9. A new Meta File is created.
  10. The created File Encryption Public Key is added to this meta file.
  11. All created location keys for the file chunks are added to this meta file.
  12. The meta file is put to the DHT.
  13. A Notification is sent to all User Clients that have access to the file.

Adding a Folder

Adding a folder is easier than adding a file, because a folder does not require a Meta File or File Chunks.

The process for adding a folder includes the following steps:

  1. The file size (configurable) is validated.
  2. The User Profile is fetched from the DHT.
  3. The Folder Index is added to the File Tree in the user profile.
  4. The user profile is put back to the DHT.
  5. A Notification is sent to all User Clients that have access to the folder.

Modify

Hive2Hive supports file versioning, meaning that multiple File Versions of a file can be stored in the network. Once a file is added to the network, it can be modified according to the file modifications on the local disk. Such modifications can only be made to files, because folders don't have a version history.

The modify process includes the following steps:

  1. The file size (configurable) is validated.
  2. The Meta File is fetched from the DHT.
  3. The modified file is split up into multiple, new File Chunks.
  4. Each new file chunk is encrypted with the File Encryption Public Key that resides in the meta file.
  5. For each new file chunk, a random Location Key is created.
  6. Each new file chunk is put to the DHT using its particular location key.
  7. All created location keys for the file chunks are added to this meta file.
  8. The meta file is put back to the DHT.
  9. In the File Index, the modified file's MD5 Version Hash is updated.
  10. A Notification is sent to all User Clients that have access to the file.

For files that are stored to the DHT, the maximum number of versions and the maximum number of bytes can be configured. Together, these two values are used to determine the amount of space a file, with all its versions, can fill. In case this space is used up, old File Versions are removed from the Meta File and the DHT.

Recover

Hive2Hive supports file versioning, meaning that multiple File Versions of a file can be stored in the network. Once a file has been modified, it can be recovered, meaning that an older file version is fetched from the network. Such modifications can only be made to files, because folders don't have a version history.

Recovering an old file version does not overwrite the newest version on the local disk, but creates a new file with a predefined suffix to indicate that it is a recovered file.

Files that have previously been deleted cannot be recovered, because the deletion operation includes all file versions.

The recover process includes the following steps:

  1. The User Profile us fetched from the DHT.
  2. The file's File Index in looked up in the File Tree.
  3. The Location Key for the Meta File is taken from this File Index.
  4. The user profile is put back to the DHT.
  5. The Meta File is fetched from the DHT.
  6. All File Chunks of the recovered File Version are fetched from the DHT.
  7. The meta file is put back to the DHT.
  8. The recovered file version is resembled from its File Chunks.
  9. A new name is created for the recovered file.
  10. The recovered file version is added to the DHT, using the created name.

Delete

Files and folders that have been added to the network can also be deleted from the network. This means that they get removed from the DHT. This deletion operation includes all File Versions of a file and is irreversible.

Deleting a File

The process for deleting a file includes the following steps:

  1. The User Profile is fetched from the DHT.
  2. The File Index is removed from the File Tree in the user profile.
  3. The user profile is put back to the DHT.
  4. The Meta File is fetched from the DHT.
  5. For each File Version, all File Chunks are removed from the DHT.
  6. The meta file is removed from the DHT.
  7. A Notification is sent to all User Clients that had access to the file.

Deleting a Folder

Deleting a folder is easier than deleting a file, because a folder does not require a Meta File or File Chunks.

The process for deleting a folder includes the following steps:

  1. The User Profile is fetched from the DHT.
  2. The Folder Index is removed from the File Tree in the user profile.
  3. The user profile is put back to the DHT.
  4. A Notification is sent to all User Clients that had access to the folder.

Move

On a local disk, files and folders can be moved from one parent folder to another. This means that the File Tree indices in the User Profile need to be updated. With this, it is not required to undertake actual file movements in the DHT.

This operation is the same for files and folders.

The move process includes the following steps:

  1. The User Profile is fetched from the DHT.
  2. In the File Tree, move the File Index or Folder Index to the new parent folder index.
  3. Put the user profile back to the DHT.
  4. A Notification is sent to User Clients that:
  • had access to the old location and have access to the new location.
  • had access to the old location, but don't have access to the new location. (Deletion request.)
  • didn't have access to the old location, but have access to the new location. (Addition request.)

Share

Folders that have been added to the network can be shared with other users. Only whole folders can be shared. The sharing includes all File Versions of the files in the shared folder. Subfolders of an already shared folder cannot be shared again.

Hive2Hive supports different Access Permissions when sharing folders.

The share process includes the following steps:

  1. The User Profile is fetched from the DHT.
  2. The sharing is validated by parsing the File Tree for already shared parent- or subfolders.
  3. A new Shared Authentication Key Pair is created.
  4. For the Meta File, replace the User Authentication Key Pair with the created, shared key pair.
  5. For all File Version, replace the User Authentication Key Pair with the created, shared key pair, for all File Chunks.
  6. In the Folder Index, add the new sharers to the Sharer List.
  7. Put the user profile back to the DHT.
  8. A Notification is sent to User Clients that:
  • had already access to the shared folder. (Update of Sharer List.)
  • are new to the shared folder. (Addition request.)

Access Permissions

Hive2Hive supports the distribution of different Access Permissions to various users when sharing folders.

Read/Write Access

This access permission allows a user to read from and write to (modify) the files in a shared folder. Furthermore, it grants the right to invite or kick other users.

So as to be able to write to files, the Shared Authentication Key Pair is shared.

Read-Only Access

This access permission allows a user only to read from the files in a shared folder.

Unshare

Folders that have been shared with other users can also be unshared with all or just some users. Only whole folders can be unshared. The unsharing includes all File Versions of the files in the unshared folder.

So as to keep the privacy, the respective folder and its enclosing content must be protected with a new File Encryption Key Pair. Otherwise, users that left the shared folder would still be able to decrypt it.

Also, to keep proper Access Permissions, the respective folder and its enclosing content must be protected with a new Shared Authentication Key Pair. Otherwise, users with read/write access that left the shared folder would still be able to modify it.

This operation has not yet been implemented, but would comprise the following steps:

  1. The User Profile is fetched from the DHT.
  2. The Folder Index of the shared folder is looked up in the File Tree.
  3. All File Indices of this folder index are looked up.
  4. Remove the unshared users from the Sharer List.
  5. Put the user profile back to the DHT.
  6. A new File Encryption Key Pair is created.
  7. A new Shared Authentication Key Pair is created.
  8. For each file in the shared folder:
  9. The Meta File is fetched from the DHT, using the respective file index as Location Key. 1. For each File Version in the meta file:
    1. Re-encrypt all File Chunks using the created File Encryption Public Key.
    2. Re-authenticate all file chunks using the created File Authentication Private Key.
  10. Replace the old File Encryption Key Pair with the created, new one.
  11. Replace the old Shared Authentication Key Pair with the created, new one.
  12. Re-encrypt the meta file using the created File Encryption Public Key.
  13. Re-authenticate the meta file using the created File Authentication Private Key.
  14. Put the meta file back to the DHT.
  15. A Notification is sent to User Clients that:
  • had already access to the shared folder. (Update of Sharer List.)
  • are unshared from the folder. (Deletion request.)