npm install fails in the vault

[ljn917]

Please agree to the following

• [X] I have searched existing issues for duplicates
• [X] I agree to follow this project's Code of Conduct

Summary

Running npm install fails in the vault with directory name collision.

What software is involved?

• Operating System: Fedora 39
• kernel: 6.10.9-100.fc39.x86_64
• Drive partition: ext4
• Cryptomator: 1.12.3-x86_64.AppImage
• FUSE: fuse-2.9.9-17.fc39.rpm from the official Fedora repo
• NPM: 10.5.0 (nodejs-npm-1:10.5.0-1.20.12.2.1.fc39.x86_64 from the official Fedora repo)

Volume Type

FUSE

Steps to Reproduce

1. Create a new local vault.
2. Create a new directory in the vault
3. Run npm i cypress@12
4. Run npm i cypress@13. This upgrade would fail.

Expected Behavior

Step 4 should succeed without error.

Actual Behavior

Step 3 usually works fine, but step 4 rarely succeeds. Step 4 often fails with errors such as failed to rename a directory or failed to create a new directory due to name collision. At the same time, cryptomator's log (cryptomator0.log) ended up with many errors like below:

WARN  o.c.cryptofs.CryptoPathMapper - Did not find valid content inside of /path/to/vault/d/FI/L3QUXQMLH2N2P7EXERJ4QZSGMJMADL/3SXF8EGqWDaU3zETxQjOgQGqXYk=.c9r
...
o.c.frontend.fuse.ReadWriteAdapter - mkdir /code/test/node_modules/qs/lib failed, file already exists.

After this, close the vault and a health check of the vault showed multiple (usually ~10) error messages like below:

CRITICAL - C9r dir /path/to/vault/d/FI/L3QUXQMLH2N2P7EXERJ4QZSGMJMADL/3SXF8EGqWDaU3zETxQjOgQGqXYk=.c9r of unknown type.

If I open the said c9r directory, it is empty. I would expect that it should contain a dir.c9r file with a UUID (please correct me if I wrong though)

In the health check UI, clicking on the Fix button would fix the issue, and the related directories above would be removed.

The directories that causes this issue seem to be random.

Reproducibility

Always

Relevant Log Output

# Health check log
CRITICAL - C9r dir /path/to/vault/d/FI/L3QUXQMLH2N2P7EXERJ4QZSGMJMADL/3SXF8EGqWDaU3zETxQjOgQGqXYk=.c9r of unknown type.

# cryptomator log
WARN  o.c.cryptofs.CryptoPathMapper - Did not find valid content inside of /path/to/vault/d/FI/L3QUXQMLH2N2P7EXERJ4QZSGMJMADL/3SXF8EGqWDaU3zETxQjOgQGqXYk=.c9r
...
o.c.frontend.fuse.ReadWriteAdapter - mkdir /code/test/node_modules/qs/lib failed, file already exists.

Anything else?

#3115 also reported a npm install failure, but it was only on MacOS and WebDAV.

[overheadhunter]

If I open the said c9r directory, it is empty. I would expect that it should contain a dir.c9r file with a UUID (please correct me if I wrong though)

Your assumption is correct. There seems to be something wrong during creation of this directory.

Maybe we can create an integration test to reproduce the problem from the npm example.

[ljn917]

Maybe we can create an integration test to reproduce the problem from the npm example.

Feel free to let me know if there's anything I can help.

[infeo]

I tested a bit around and my current assumption is a cache invalidation problem.

We have a class called CryptoPathMapper, which stores for 20s the last cleartext->ciphertext mappings. If i wait approx. 25s, step 4 runs fine. If i only wait approx. 15s, step 4 reports errors.

Note: There is also the LongFileNameProvider, which contains a cache with a timebased eviction policy. But that should only trigger after 60s.

[ljn917]

Thank you very much for your testing. I confirm I observe the same timing for reproducing this problem. 20s seems to be the threshold to trigger it.

[infeo]

Depends on https://github.com/cryptomator/cryptofs/issues/252

[infeo]

Fixed by updating to cryptofs-2.8.0-beta1 in adaf9ef5ced8b5acf7e6834d9e8a39279cb008a8