Cyberduck Mountain Duck CLI

#10029 closed defect (fixed)

Problems syncing folder in a Cryptomator vault on a remote volume (OneDrive / Google Drive / Dropbox)

Reported by: frdesch Owned by: dkocher
Priority: high Milestone: 6.2.1
Component: cryptomator Version: 6.1
Severity: major Keywords:
Cc: Architecture: Intel
Platform: Windows 7

Description

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

Change History (3)

comment:1 Changed on Jul 27, 2017 at 1:10:34 PM by dkocher

  • Component changed from core to cryptomator
  • Milestone set to 6.3
  • Owner set to dkocher
  • Status changed from new to assigned

comment:2 Changed on Aug 7, 2017 at 11:49:20 AM by dkocher

  • Resolution set to fixed
  • Status changed from assigned to closed

In r42206.

comment:3 Changed on Aug 7, 2017 at 11:50:11 AM by dkocher

  • Milestone changed from 6.3 to 6.2.1
Note: See TracTickets for help on using tickets.
swiss made software