No files visible in a vault on OneDrive on Windows 10 1709

[ralfruether]

After upgrading to new Cryptomator and to new vault version, no files are visible on my business computer with Windows 10 1709. No issues on my personal computer with Windows 10 1909.

Vault files are stored on OneDrive for Business in both cases. Log shows that files are ignored due to IO errors.

log extract.txt

[overheadhunter]

10:35:57.261 [Thread-82] DEBUG o.c.frontend.dokany.ReadWriteAdapter - (13) findFiles(): IO error accessing FILE. Will be ignored in file listing.

This log entry is created here, meaning that reading the file attributes fails on your Win 10 1703 machine for some reason.

@infeo In case of (unexpected) exceptions, can we change logging to always use the form LOG.warn("foo happend at file " + file + ". bar baz.", e), so we don't loose the stack trace?

[ralfruether]

Actually it's Windows 10 1709, I corrected that above. I also added a log statement to print the stacktrace after the line you pointed out, which results to the following for each file:

10:33:06.072 [Thread-150] DEBUG o.c.frontend.dokany.ReadWriteAdapter - (22) findFiles(): IO error accessing /Reklamation Festplatte bei K&M.doc. Will be ignored in file listing.
10:33:06.073 [Thread-150] DEBUG o.c.frontend.dokany.ReadWriteAdapter - findFiles(): Message and Stacktrace.
java.nio.file.NoSuchFileException: /Reklamation Festplatte bei K&M.doc: Could not determine type of file C:\Users\<anonymized>\Personal\d\MF\GPTQJHYV6WH3HG3XMJVOGRSKARPZ7C\0RJfs5RI-xfdYFOmBnENaVJzGh1u8lHDWxwyEyeBQZ5ag8fufkmucuuuoKyIg_e8LRE=.c9r
    at org.cryptomator.cryptofs.CryptoPathMapper.getCiphertextFileType(CryptoPathMapper.java:107)
    at org.cryptomator.cryptofs.attr.AttributeProvider.readAttributes(AttributeProvider.java:41)
    at org.cryptomator.cryptofs.CryptoFileSystemImpl.readAttributes(CryptoFileSystemImpl.java:235)
    at org.cryptomator.cryptofs.CryptoFileSystemProvider.readAttributes(CryptoFileSystemProvider.java:423)
    at java.base/java.nio.file.Files.readAttributes(Unknown Source)
    at org.cryptomator.frontend.dokany.ReadWriteAdapter.lambda$findFiles$0(ReadWriteAdapter.java:515)
    at java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
    at java.base/java.util.Iterator.forEachRemaining(Unknown Source)
    at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Unknown Source)
    at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source)
    at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
    at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(Unknown Source)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(Unknown Source)
    at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source)
    at java.base/java.util.stream.ReferencePipeline.forEach(Unknown Source)
    at org.cryptomator.frontend.dokany.ReadWriteAdapter.findFiles(ReadWriteAdapter.java:529)
    at com.dokany.java.DokanyOperationsProxy$FindFilesProxy.callback(DokanyOperationsProxy.java:138)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.base/java.lang.reflect.Method.invoke(Unknown Source)
    at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520)
    at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)

[ralfruether]

Did some more debugging. Exception is thrown here, because file attributes states that it is whether a regular file nor a directory.

[overheadhunter]

So I assume you can also change code in cryptofs? It might be worth a try removing the exception and changing the code to:

if (attr.isDirectory()) {
    if (Files.exists(ciphertextPath.getDirFilePath(), LinkOption.NOFOLLOW_LINKS)) {
        return CiphertextFileType.DIRECTORY;
    } else if (Files.exists(ciphertextPath.getSymlinkFilePath(), LinkOption.NOFOLLOW_LINKS)) {
        return CiphertextFileType.SYMLINK;
    } else if (Files.exists(ciphertextPath.getFilePath(), LinkOption.NOFOLLOW_LINKS)) {
        return CiphertextFileType.FILE;
    }
} else {
    // assume file for all other file types:
    return CiphertextFileType.FILE;
} 

[overheadhunter]

Btw: What does Windows say about the type of the node at d\MF\GPTQJHYV6WH3HG3XMJVOGRSKARPZ7C\0RJfs5RI-xfdYFOmBnENaVJzGh1u8lHDWxwyEyeBQZ5ag8fufkmucuuuoKyIg_e8LRE=.c9r?

[ralfruether]

Seems to work so far, after changing method to

    public CiphertextFileType getCiphertextFileType(CryptoPath cleartextPath) throws NoSuchFileException, IOException {
        CryptoPath parentPath = cleartextPath.getParent();
        if (parentPath == null) {
            return CiphertextFileType.DIRECTORY; // ROOT
        } else {
            CiphertextFilePath ciphertextPath = getCiphertextFilePath(cleartextPath);
            BasicFileAttributes attr = Files.readAttributes(ciphertextPath.getRawPath(), BasicFileAttributes.class, LinkOption.NOFOLLOW_LINKS);
            if (attr.isDirectory()) {
                if (Files.exists(ciphertextPath.getDirFilePath(), LinkOption.NOFOLLOW_LINKS)) {
                    return CiphertextFileType.DIRECTORY;
                } else if (Files.exists(ciphertextPath.getSymlinkFilePath(), LinkOption.NOFOLLOW_LINKS)) {
                    return CiphertextFileType.SYMLINK;
                } else if (Files.exists(ciphertextPath.getFilePath(), LinkOption.NOFOLLOW_LINKS)) {
                    return CiphertextFileType.FILE;
                }
            } else {
                // assume file for all other file types:
                return CiphertextFileType.FILE;
            }
            throw new NoSuchFileException(cleartextPath.toString(), null, "Could not determine type of file " + ciphertextPath.getRawPath());
        }
    }

Regarding type I'm not quite sure what you are looking for, but the following pictures might answer your question:

[infeo]

The attribute letter L indicates this file is a reparse point. I think this is the reason why Java does not detect it as a regular file.

[overheadhunter]

@cryptomator/libraries Can we adapt this change? Do any of you see any risk of incorrect behaviour when assuming any non-directory .c9r node being assumed to be a file?