search

cryptomator / cryptofs

Java Filesystem Provider with integrated encryption
GNU Affero General Public License v3.0
94 stars 35 forks source link

Restoring a deleted folder in vault causes 'Broken directory file' #20

Closed DesmondKong closed 1 year ago

DesmondKong commented 6 years ago

Environment

2 Windows 7 PCs with Cryptomator 1.3.3 and ownCloud Client for vault sync.

Steps to reproduce

  1. OnPC 1, create new vault.
  2. Sync vault and open vault on PC 2.
  3. On PC 1, drag a folder X containing a single file into vault. Folder X appears on PC 2.
  4. On PC 1, delete folder X. Folder X disappears on PC 2.
  5. On PC 1, restore folder X by dragging into vault again. Folder X does not appear on PC 2 after sync.

Expected result

On PC 2, Folder X should appear on vault.

Actual result

On PC 2, Folder X does not appear after sync. Folder X will appear only when vault is locked and unlocked again.

Fix #16 could be related but did not work in this scenario.

Log

WARN o.c.cryptofs.CryptoDirectoryStream - Broken directory file [redacted]\cvault\d\YY\MTPN4VZHCX7YBMO5H2VTRLRS5JHSQ6\0NIEDU7NAVQ6GQNW7F6MX6NUK32CKM7SBLGRA====. Directory [redacted]\cvault\d\DN\5XWE3MRQFHTJOBY3VLFRZHJ4CN6KDE does not exist.

Thank you!

tobihagemann commented 6 years ago

Just from reading this issue, I can imagine what happens. As far as I know, directory ids are cached. Since you're re-creating the folder (in step 5), the directory gets a new id and the respective directory path is different than before.

As the saying goes:

There are only two hard things in Computer Science: cache invalidation and naming things.

Not sure what a smart strategy would be to invalidate the directory id cache in this case but I'm fairly certain that this is the issue.

DesmondKong commented 6 years ago

It looks like that's the case. The directory gets a new ID in step 5 on PC 1 and PC 2 is oblivious to the change. I'm not sure how the caching mechanism works, but is it possible to attempt a reload on the affected directory structure whenever it (broken directory file) happens?

markuskreusch commented 6 years ago

Yes, a reload is what we should do in this case.

infeo commented 6 years ago

uup, sorry the above commit should reference issue #29...

overheadhunter commented 5 years ago

As far as I know, directory ids are cached. Since you're re-creating the folder (in step 5), the directory gets a new id and the respective directory path is different than before.

Cryptomator 1.3.3 uses CryptoFS 1.4.5.

CryptoFS 1.4.5 invalidates the cached directory ID. Cache invalidation is still missing for recursive deletion done by the DeletingFileVisitor since CryptoFS 1.5.0¹, but it should not be the cause of the problem described in this issue.

¹ Edit: My mistake: The DeletingFileVisitor is just recursively deleting the ciphertext directory (which has no subdirectories due to our directory structure flattening). Recursive deletion is not supported by the API at all. You need traverse using a FileVisitor.

infeo commented 1 year ago

Broken directories can be restored via the health api since cryptofs 2.1.0.