-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create dir id file on vault creation #146
Comments
I disagree:
|
True, but the root dir is also a special dir.
I would say this is a false assumption. The vault checks, results and fixes are for objects within the vault structure. If the directory lies around in some l+f dir is not something the health checks targets for. Additionally, we could with high probability determine by folder name, if it is the root folder by hashing the constant root dir. Admittedly, the advantage is insignificant: One point of failure less because no file is created and it cannot appear as a result. On the other hand, the benefits are also tiny: we can identify a folder somewhere in the filesystem as a deleted/moved root folder with more confidence. |
Ok, one posssible case would be, if the encrypted root directory is renamed. Because then it cannot be deteremined as the root by name. And if that is the case, it is detected as an orphan. And can be recovered. Note: I noticed that during an oprhan fix, the root directory will be implicitly created. Which is good! because otherwise the user would still have no access to the vault... |
How so? It should be treated equally.
Your fix implies that the root dir should not have said file and thus doesn't offer to "fix" it. Which defies the purpose of the file to help during data recovery. Data recovery is important regardless of whether the folder is "inside" the |
I changed the implementation to create the dirId backup on vault init.
Yes, data recovery is important, but from my point of view we also need to keep a clean scope of the health check. The scope is build from the answers of "Where is the health check applicable? What can it check? What should it check? And what should be fixed?". For the first question it is: A directory structure detected as a cryptomator vault. Not some ciphertext directory somewhere in the filesystem. Essential things like the config or the masterkey would be missing. If someone willingly destroys the vault strucuture, there is not much we can do. We could try such an "whatever it costs"-recovery-approach in a separate project, but I strongly suggest to keep the scope narrow for the cryptofs internal health check. A (at least for me) convincing example is that due to some fs hickup, the cipher root dir is renamed. Then we can assume that this renamed cipher dir belongs to the surrounding vault structure and we have key and config material to actually recover data. |
The directory id for the root dir a constant, furthermore the root cannot become orphaned (where the backup comes into play).
Hence the root should be excluded for the dirIdBackup
The text was updated successfully, but these errors were encountered: