Sharing Concept Shared Folder

Note: This is part two (of three) of creating a concept for file identifiers. Part one can be found here, part three here

Overview

• Using FileHash as FileID
• Creating FileID on Initial ShareRequest
• File IDs in the DHT

Approaches of Identifying Files

Since files are not required to be stored at the same path on the owner's side and the sharer's side, files must be uniquely identified. One approach was to use the initial file content hash as a file id. The second approach, consists of generating an UUID on creating the initial share request.

Using the FileHash as File ID

Using the first approach, i.e. taking the file hash as unique identifier, results in an issue when having two files with the same hash in different shared folders on the original client as well as on the sharer:

Client 1
========

|- dir11
|  |
|  |- innerDir11 
|  |  |
|  |  |- sameHashFile.txt (shared with Client2)
|  |
|  |- innerDir12 
|     |
|     |- file.txt
|     |- sameHashFile.txt (shared with Client2)
|
|- sharedWithOthers

Since the both files are equally named, they must be renamed in the shared folder on client2 (append a counter to the end, for example).

Client 2
========

...
|
|- sharedWithOthers
|  |
|  |- sameHashFile.txt
|  |- sameHashFile (2).txt

Now, if the sameHashFile.txt in the innerDir11 gets changed, a modify event for the old and the new path is emitted as well as the relative path to the shared file. The structure will be something like the following:

{
  "relFilePath": "sameHashFile.txt",
  "oldHash": "<oldHashGoesHere>",
  "newHash": "<newHashGoesHere>"
}

As we see in this example, the very same event would occur for the sameHashFile.txt in the innerDir12. Client2 will be unable to clearly identify which file has really changed, and will therefore only update the first sameHashFile.txt but never the locally renamed one sameHashFile (2).txt.

Creating a File ID on initial share request

The second approach makes use of the protocol for adding, modifying and removing files on the own clients: Sharing a file or directory should be equally handled, meaning that a file offering request has to be sent to all other own clients, making sure, that no other client is sharing the same file at the same time.

Once this step has been accomplished, the PathObject from the ObjectStore is read and checked whether a file id is already existing (from an earlier share). If this did not happen beforehand, we can now safely create a new file id and send the ShareRequest (for the sharer's client (select only one)) and FileSharedRequest (for all own clients).

The client which receives the ShareRequest will then initiate a FileDemandExchange to fetch the shared file. All own clients will persist the new sharer and the file id to their own object stores.

There exists a scenario in which the second approach is causing conflicts on the fileId. Imagine the following: Two sets, each having two clients of the same user (C11, C12) and (C21, C22) are operating concurrently on the same file, i.e. are trying to share the same file to an user. Due to lost network messages, they are not able to communicate with each other. Now, if they share the file, two different fileIds will be generated and therefore two different files on the sharer. Updates made will be propagated only to one set of clients. Once both sets will get to know them, they get a conflict on the same file, having two different fileIds for the same original file. Therefore, a different approach had to be developed

File IDs in the DHT

The third and implemented approach consists of storing file ids in the DHT. Read more about this approach here