56d250b created the issue

Hello

My config : Windows 7 64 bits up to date; Cyberduck 6.1.0 (25371); Mountain Duck 2.0.0 beta (7237); both highly interesting with the integration of Cryptomator !

Case with OneDrive : syncing between a local folder and a folder on a remote One Drive Personal volume.
If the folder on the Onedrive volume is not in a vault, all is ok (upload, sync,..)
But if the folder on the Onedrive volume is in a vault :
-initial upload of a local folder in a remote folder in the vault with “upload” is ok.
-but then if I try either “upload” again or “sync” with upload or mirror option, the comparison list cannot be displayed, process stops with error message "Access denied - encrypted file size must be at least 88 bytes"
Does not depend on the type of local folder (tested with ‘normal’ local folder, folder in a local vault, folder in a Truecrypt container, folder in a vault in a truecrypt container (yes!)); seems to be directly related to the fact that the remote folder is in a vault on the remote OneDrive Volume
As I read somewhere there could be problems with folders at the root of the vault, I tested with folders deeper in the vault : same problem

Same test with a Google Drive volume :
If remote folder not in a vault : ok (upload, sync). Modification date are kept unchanged : great !
If in a vault :
-“upload” : initial upload : never achieve, stays on “changing timestamp ”, have to cancel (by closing the Transfers window)
-when I retry : fails with “Access denied, invalid file size”
-2nd retry : cyberduck freezes; have to forceclose; message “there are files currently being transferred, qui anyway ?”. Problem : even after a while, same message, so forceclose.
When looking in File Explorer (Google drive volume mounted with Mountain Duck) : only the folder was created, empty, no file transfer in it.
-3rd retry (wait a longer time) : after several minutes, ends by ‘transfert incomplete’
Idem : When looking in File Explorer (Google drive volume mounted with Mountain Duck) : only the folder was created, empty, no file transfer in it.

Same test with a Dropbox volume :
If remote folder not in a vault : ok (upload, sync). Modification dates are set to the current date : too bad…
If in a vault :
-“upload” : initial upload : ok. But Modification dates are set to the current date : too bad…
-“sync/mirror” or “sync/upload” : ok (even if the “apply mirror/upload filter” step is long (>2mn for 7 small files in 2 subfolders…). Same problem with modification date
So it seems to be ok with Dropbox, except modification date set to the current date.

Hope these tests can bring you useful information.

And once again, all my congratulations for the work of your team !

Thank you for your help.

François DESCHAMPS