The system cannot find the file specified (Cryptomator)

Support
#1

TWO ERRORS BEING ADDRESSED HERE:

  1. targetfolder readlink C:\Users\user\folderholdingtarget: The system cannot find the file specified.

  2. Failed to create folder root directory mkdir \?: The filename, directory name, or volume label syntax is incorrect.

Cryptomator normally unlocks your encrypted files and displays them in a temporary mounted drive. That drive by default, for Windows, is F:. I attempted to sync a folder to that directory, but got an error like this. The directory location is correct and the test folder is present as well.

image
image1167Ă—230 7.96 KB

I created a new folder, 1EVM, in my users folder and then pointed Cryptomator to that folder. I did this to bypass the mount issue from the previous image. Even though the folder is recognized as just that by the system on creation, the folder is turned into a mounted volume when Cryptomator sends the decrypted files there for user interaction.

EXAMPLE BELOW

DIRECTORY PROPERTIES
DIRECTORY PROPERTIES510Ă—537 76.7 KB

WHAT 1. LOOKS LIKE ON THE GUI (target folder is inside ~\1EVM directory)

SYNCTHING GUI WITH ERROR
SYNCTHING GUI WITH ERROR1937Ă—1097 315 KB

CRYPTOMATOR GUI

CRYPTOMATOR
CRYPTOMATOR1164Ă—892 137 KB

I don’t know if this is considered a virtual drive, but I think it’s something that should be investigated. I was able to get it to work temporarily when I created a new folder, pointed Cryptomator to it, unlocked the vault and pointed Syncthing to that same directory. Once I restarted the system then that’s when 1. came up. Even with 1. showing all the files where there. I think the errors reported something about recursion detection.

#2

!- UPDATE - !

I was able to get it to work partially when I created a new folder on the C:\ drive, pointed Cryptomator to it, unlocked the vault and pointed Syncthing to that same directory. The 1. still shows and the synchronization only works for the initial/first sync. It won’t work for any changes in that directory post initial/first sync. It freezes at “Preparing to Sync” and the error also prevents manually re-scanning of the target directory.

EXAMPLE BELOW

LOCAL SYNC STATUS

DETAILS ON FAILED ITEMS

INFINITE FILESYSTEM RECURSION DETECTED
INFINITE FILESYSTEM RECURSION DETECTED1019Ă—891 136 KB

#3

Is there any specific reason for using Cryptomator (or other similar solution) in combination with Syncthing?

Syncthing already encrypts all its traffic, so there is no need to add additional encryption on top of it. The only situation that I can think of is if you want to sync the same files using other non-enrypted cloud services (e.g. Dropbox, Google Drive, etc.) at the same time.

I would also suggest searching the forum, as it seems that other people have had similar problems. Please check https://forum.syncthing.net/search?q=cryptomator.

#4

I’m aware that the files are encrypted during transport, but not on the local machine. If Syncthing community developers added a local directory encryption feature, that would remove the need of Cryptomator. This is the most practical option for cross-platform use cases at the time of this post. Do you have any suggestions?

#5

Do you absolutely need to use the same solution on all platforms? I personally do encrypt my files whenever possible, but mostly I stick to the built-in solutions, i.e. BitLocker on Windows, system encryption on Android, etc.

VeraCrypt is cross-platform and should work fine with Syncthing, but it also has some performance issues, so I cannot really recommend it.

#6

I honestly prefer Axcrypt, but that isn’t an option for linux based OS. Interoperability is missing with encryption based software and is now very apparent when connecting different devices together with different runtime environments. Axcrypt on Linux would evolve the game. I will have to use a combination of methods for the desired results now. Hopefully an update can handle interactions with CryptoMator better in the future.

#7

I have just done some testing with Cryptomator, and

  1. The file watcher does not work with the virtual file system, but you can disable it and still use periodic scanning.

  2. The infinite recursion error can be worked around by using UNC paths, e.g.

    image
    image704Ă—250 16.4 KB

1 Like
#8

  1. I figured this out earlier in the day. You just confirmed. For now I’ll just decrease the interval times.

  2. I assume UNC ~ UNIVERSAL NAMING CONVENTION?

#9

Yes, but as the screenshot shows, what I wanted to say is that you just need to prefix your paths with \\?\.

#10

This is surprising as we already always add the \\?\ prefix to paths if it’s missing, internally. (Apart from the fact that it shouldn’t matter anyway since the recursion detection is based on returned file IDs.)

1 Like
#11

SCENARIO:

FOLDER A ~ 20 GB ON MACHINE B

FOLDER A ~ 20 GB ON MACHINE C

I copied a directory from another device on the network to save time on synchronization and local bandwidth because a file of this size can take some time. The copied directory was placed in a virtual mounted drive created by CryptoMator. I used the UNC as mentioned and this is what I found.

\\?\F:\targetfolder

UNC ERROR STILL

  1. Copying everything excluding the .stfolder (Syncthing will create a new one), The syncing bar remains at 0%. Sometimes it goes up a few percentage points then resets back to 0%

  2. Copying everything including the .stfolder, the same thing occurs. *Syncthing will create a new .stfolder that will override the one in the directory so it really doesn’t make a difference.

Reason I came across this was from copying everything from a folder that was manually created for testing with Cryptomator and placing it in the virtual mounted drive created by Cryptomator automatically. Synchronization isn’t questionable at times. I’m not 100% sure if this would be the same if the virtual drive wasn’t in the equation. I did the same thing with a smaller sized directory and as soon as the folder was added it posted Up to Date on the folder status. It would be best to pull the directory from scratch when dealing with virtual drives.

Screen Shot 01-23-21 at 07.03 PM

  1. When a fresh synchronization is successful with a virtual drive, everything will seem normal. The folder say Up to Date. Any changes made to the directory afterwards will throw a recursion error. Regardless if watch for changes is enabled or not. The file watcher still works watch for changes toggled so it’s logical to just leave it on. A feature to ignore that error when dealing with virtual drives maybe?
#12

Maybe. It seems a lot of virtual filesystem type things don’t really emulate an actual Windows filesystem that well.

#13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.