With the merge of https://github.com/cryptomator/cryptofs/pull/149, a result returns an Fix object, which represents the fix for the result (meaning that after applying the fix, the result does not appear again in a subsequent check).
Still, a key problem is not fixed: How to resolve conflicting (aka affecting the same resource) fixes?
It is explicitly spoken of fixes not only results, because a fix can affect more paths than just the result-causing ones. Example
Result A reports a file at the wrong place /Foo/Bar.c9r. The Fix is to move it to /Baz/Bar.c9r.
The result-causing paths are only /Foo/Bar.c9r, but the fix-affected paths are /Foo/Bar.c9r and /Baz/Bar.c9r.
Every fix alters the state of the filesystem, hence, subsequent fixes (including the same fix) might fail. Currently, the health API does not account for that and only reports all problems of the current filesystem state. The consumer can only execute one fix after another and rerun the health check(s) to fix previously failed fixes.
With the merge of https://github.com/cryptomator/cryptofs/pull/149, a result returns an
Fixobject, which represents the fix for the result (meaning that after applying the fix, the result does not appear again in a subsequent check).Still, a key problem is not fixed: How to resolve conflicting (aka affecting the same resource) fixes?
It is explicitly spoken of fixes not only results, because a fix can affect more paths than just the result-causing ones. Example
Every fix alters the state of the filesystem, hence, subsequent fixes (including the same fix) might fail. Currently, the health API does not account for that and only reports all problems of the current filesystem state. The consumer can only execute one fix after another and rerun the health check(s) to fix previously failed fixes.