Hi,
I have the following problem: There is a vault that is syncronized via a cloud service; multiple people have access to the vault via the cloud service. If two people edit a file at the same time (e.g. Word file), it seems that the encrypted file does not get a file lock, so it can be overwritten. This can lead to inconsistencies because the syncronization algorithm cannot detect the conflict.
Example: A and B open a file. A and B change something; in the end it will be decisive which of the two saves last; the changes of the other will be lost without warning.
Do I see this correctly (hence the message in the help section) and if so, would it be possible to change this?
Do I see this correctly (hence the message in the help section) and if so, would it be possible to change this?
No and no.
This can lead to inconsistencies because the syncronization algorithm cannot detect the conflict.
This is a wrong conclusion. Or, well, it depends on your sync client what happens if two people edit the same file. If the file is locally stored and edited, normally the sync client notices a conflict during upload and creates two files, one named regularly ( e.g., file.txt) and the other one with a pre- or suffix added (like file_conflict(01-01-1994).txt).
would it be possible to change this?
Cryptomator does not provide direct synchronization functionality, it only en-/decrypts files with optimizations for cloud storage and synchronization patterns. The actual upload is done by the sync client.
What happens, if B saves his changes locally, which are synced to the cloud and back to A who has not saved any changes yet. Now A saves its changes which are synced back to the cloud and then to B. How should the sync client be able to detect that the other person is also working on the file, if its not locked?
I’m just a newbie user, but I think you see it correctly.
Whenever you have two people editing the same document you can expect those kind of problems unless there is some software to help manage the document changes. Some services like microsoft office on onedrive can support that, but I don’t think they can accomplish that if their server is only seeing the encrypted files.
As @infeo already wrote, conflicts are usually detected by the sync clients.
Cryptomator files are just files for the sync client.
The clients „know“ meta data of files (also of encrypted files) and can recognize if a file was changed online and can detect conflicts.
Example:
Client a is downloading a file and saves its timestamp x.
Client b is downloading the same file and also saves the timestamp x
Client a does upload a modified version that has now timestamp y
Later on, client b wants to upload also a modification of file a, but recognise that the now existing online version of the file does not have timestamp x anymore, but has timestamp y. So client b knows that the online file was changed by someone else.
If the client b cannot merge the changes of the online file with timestamp y and the changes made to the local file in client b (which is usually the case if files are encrypted), then client b creates a second file as described by @infeo
Please note: this is just an example. I am not sure if the detection of conflicts does only rely on timestamps.
This is a client behaviour and not triggered or influenced by Cryptomator.
Michael, in my example the timestamp will not help, as the syncing has happened before A is saving his changes For the sync client there is no timestamp conflict:
The original file has timestamp x everywhere.
A and B are working on the file at the same time.
Now, B is saving his changes at time y. So his sync client detects the change and syncs the newer version to the cloud. The newer version with timestamp y is also synced from the cloud to A.
Now, A has the changed version of the file on his filesystem, but he has still opened the version with timestamp x.
At a later time z A is saving his changes. His sync client recognizes timestamp z is newer than timestamp y and syncs to the cloud. The cloud syncs to B because of the same reason.
Now, B has the newest file with timestamp z, but this version does not contain his changes.
The problem is the first sync to A. The sync client does not have the information that this version has not been changed yet, but someone is working on it. That information has to be provided by the file system, as the sync client cannot know that. In a normal file system (without Cryptomator) that will be indicated by locking opened files. In that case the sync cient will not touch the opened file, but produces a conflict. Cryptomator does not lock the encrypted file when its decryption is in use. So Cryptomator does not provide a information to the sync client that is normally provided by the file system and that the sync client relays on.
No. The sync client does not simply overwrite a file which is in use with a never one on the cloud.
This would make conflict detection useless and would be a total mess when working with online files.
why not. The sync client has always all meta information about a file and typically stores this information. So the sync client can detect at any time if the file it downloaded the last time is still the file that’s actually online and sync the modified file to the online storage. And if it does not match (which means someone else has changed it since the last download) and if there’s no function to merge content (which is not for encrypted files), then there’s a conflict detected.
That is why I opened that discussion: The sync client just sees the encrypted files in the real file system. If one of those files is opened in the vault, the file will be marked as opened in the vault, but not in the real file system. There the encrypted file is not marked as opened. That information gets lost during processing. The sny client cannot do its job, which is to detect that the encrypted file is open or not. I have already tried it (with Owncloud which syncronizes very well).
If one of those files is opened in the vault, the file will be marked as opened in the vault, but not in the real file system.
Files can be locked to protect from modification. But this is only done upon request from an application accessing the file, not by Cryptomator itself.
As an alternative, applications which load a file into memory compare on save the lastWrite timestamp and if it changed, notify the user.
EDIT - Deleted my previous comments. I was thinking about the scenario where a cloud service (MS OneDrive and Google) intentionally allows multiple people simultaneously editing the same document as a team collaboration feature (obviously that wouldn’t work well with cryptomator). I didn’t closely read the original question which was about something quite different (file locking to prevent simultaneous editing).
I don’t know if that’s possible. But wouldn’t it be useful if Cryptomator also makes a lock request for a file opened in the vault in the real file system, thus for the encrypted file. Then the sync client could detect encrypted files in use.
AlexO – I’ll just mention a potential “workaround” that might be helpful in some situations (like small group): All collaborators could agree on a temporary renaming convention to signify when a document is “checked out” for editing. For example: you might append your initials to the end of the filename when you start editing it; and remove those initials from the end of the filename when you finish editing it. That way, if you begin that process and you see that someone else’s initials are already there, you know someone else is already editing it. Even if they just started editing and you haven’t refreshed your display yet, you’d still get an error message because the original named file (without the added initials) is no longer there, so I think it’s foolproof in terms of preventing double editing (there is no way two different people could both rename the same file without one of them getting an error).
That’s obviously increased effort and subject to human errors (forgot to rename the file before or after editing) and not as good as an automated solution.
To follow up on the discussion above, we observed the same issue with a Cryptomator vault placed on a shared SMB drive without any cloud/sync involved. When two different users open the same Word file from the shared vault, Cryptomator does not inform the second user about the file being already locked. As a consequence, both users can write to the file, which is causing unexpected results and data loss.