targetfolder readlink C:\Users\user\folderholdingtarget: The system cannot find the file specified.
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.
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.
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.
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.
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’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?
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.
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.
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.)
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
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%
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.
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?
