I just did a fresh install of Linux Fedora 43, installed Dropbox and synced my files (including a Cryptomator vault), installed Cryptomator and opened the vault. On opening, there was an event notification reporting a broken filesystem node. I get the same notification for this Dropbox vault on my laptop running Windows 10, which connects to the same vault via Dropbox + Cryptomator.
The broken node is a long string with .c9r at the end, as referenced e.g. here. When I select the option “Show broken, encrypted node,” it takes me to a folder in the encrypted vault which has no contents.
When I choose the option “Copy decrypted path for this broken filesystem node,” I get the same result on both computers: it’s just a .tmp file located in the main mount point directory for the unlocked vault. It seems like maybe with all the dropbox activity and other stuff from my fresh OS install, the Dropbox sync and/or Cryptomator setup had a little hiccup with a single .tmp file. Hopefully this means it’s not a serious error? Can I get away with selecting the option to dismiss this event? Would deleting the empty .c9r folder address the issue?
the exact nature of the problem, since it was not attributable to a discrepancy in file syncing at the time when I noticed the error– the same event occurred for this vault on two separate computers with two separate local syncs of the Dropbox folder
the meaning of “Copy decrypted path for this broken filesystem node”– it seems this indicated that the event was due to a random .tmp file being expected but not found in the main decrypted vault folder / mount point. But I didn’t want to assume as much given the potential danger of being wrong about that, and there was no documentation in the program or on the website describing what this means exactly.
the severity of the problem– it seems to be localized to one random missing .tmp file, but I can’t be 100% sure about that given the above, or whether this seemingly small and localized issue is potentially indicative of other corruption issues either present now or potentially to arise in the near future.
Given all the ambiguity around this, I did not feel completely comfortable with just relying on the fix in the health check to address the issue. What I wound up doing instead was
make an unencrypted copy of the decrypted corrupted vault (whose contents seemed fine as far as I could tell, apart from the apparent encryption issue relating to the missing .tmp file)
make a new Cryptomator vault from the decrypted local copy
verify that the new vault had no broken filesystem node events or other corruption issues (it didn’t)
delete the old, corrupted vault on Dropbox and upload the new, uncorrupted one
Again, due to all the ambiguity in the documentation around this, I can’t feel 100% sure that the copy of the vault I made from the decrypted contents of the old, corrupted vault is really 100% OK, even though it seems to be OK from what I can tell, both in terms of its actual decrypted contents and what Cryptomator is telling me about the health of the encrypted vault.
You can always dismiss an event. If it appears only one or two time, it might have been a sync issue.
In your case, maybe the cleartext directory/file should have been deleted, but the delete operation was interrupted while deleting the .c9r directory: Before a directory can be deleted, first all content has to be deleted. If this process is interrupted, the left overs can lead to a “Broken Filesystem Node”. Since the file name ends with “.tmp”, i think it is safe to delete.