[Cyberduck-trac] [Cyberduck] #10029: Problems syncing folder in a Cryptomator vault on a remote volume (OneDrive / Google Drive / Dropbox)

[Cyberduck]

#10029: Problems syncing folder in a Cryptomator vault on a remote volume (OneDrive
/ Google Drive / Dropbox)
------------------------+-----------------------
    Reporter:  frdesch  |      Owner:
        Type:  defect   |     Status:  new
    Priority:  high     |  Milestone:
   Component:  core     |    Version:  6.1
    Severity:  major    |   Keywords:
Architecture:  Intel    |   Platform:  Windows 7
------------------------+-----------------------
 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
 <name of the folder to sync>”, 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

--
Ticket URL: <https://trac.cyberduck.io/ticket/10029>
Cyberduck <https://cyberduck.io>
Libre FTP, SFTP, WebDAV, S3 & OpenStack Swift browser for Mac and Windows