You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cyberduck seems to be rewriting local paths to always be rooted from the C: drive, even if the real source is another drive or UNC path. Local and Network paths are affected. This definitely affects FTP and SFTP, I'm guessing it affects all protocols.
Examples:
ALL uploads, initiated via Keyboard (Alt+Up), Context Menu, File Menu, or Drag & Drop fail on all non-C: drive local paths. All paths have their local drive (D:, E:) or UNC server (\Server) rewritten to C:. Of course, since the file isn't actually there, the transfer fails.
Drag & Drop Downloads to paths not on C: drive have also have their leading identifier (e.g. D: or \Server) rewritten to C:. Transfers succeed, but the local path is rerooted to the C: drive. If a file was to be downloaded to D:\Path\To\File.zip, then the file is downloaded to C:\Path\To\File.zip. The \Path\To directories are created on C: if they do not exist. This happens for all non-C: local drives, mapped network drives, and UNC paths.
The "Download To..." command works correctly.
If the default download folder specified in Preferences -> Transfers -> General -> Downloads -> Download Folder is not on the C: drive, then the "Download" command fails in a similar manner as Uploads and D&D Downloads.
The text was updated successfully, but these errors were encountered:
Cyberduck seems to be rewriting local paths to always be rooted from the C: drive, even if the real source is another drive or UNC path. Local and Network paths are affected. This definitely affects FTP and SFTP, I'm guessing it affects all protocols.
Examples:
ALL uploads, initiated via Keyboard (Alt+Up), Context Menu, File Menu, or Drag & Drop fail on all non-C: drive local paths. All paths have their local drive (D:, E:) or UNC server (\Server) rewritten to C:. Of course, since the file isn't actually there, the transfer fails.
Drag & Drop Downloads to paths not on C: drive have also have their leading identifier (e.g. D: or \Server) rewritten to C:. Transfers succeed, but the local path is rerooted to the C: drive. If a file was to be downloaded to D:\Path\To\File.zip, then the file is downloaded to C:\Path\To\File.zip. The \Path\To directories are created on C: if they do not exist. This happens for all non-C: local drives, mapped network drives, and UNC paths.
The "Download To..." command works correctly.
If the default download folder specified in Preferences -> Transfers -> General -> Downloads -> Download Folder is not on the C: drive, then the "Download" command fails in a similar manner as Uploads and D&D Downloads.
The text was updated successfully, but these errors were encountered: