Cyberduck
Mountain Duck
CLIOpened on Mar 8, 2011 at 4:20:49 PM
Closed on Mar 10, 2011 at 5:19:46 PM
Last modified on Jan 7, 2012 at 8:27:12 AM
#5749 closed defect (fixed)
Uploading folders fails
| Reported by: | jfingas | Owned by: | dkocher |
|---|---|---|---|
| Priority: | high | Milestone: | 4.0.1 |
| Component: | core | Version: | 4.0 |
| Severity: | major | Keywords: | upload |
| Cc: | Architecture: | Intel | |
| Platform: | Mac OS X 10.6 |
Description
CyberDuck 4.0 introduced an arbitrary limitation where it only allows one file to be sent at a time through drag-and-drop, at least in Mac OS X 10.6.6. This must be fixed to restore multi-file drag-and-drop, since it's a serious step backwards for the entire client.
Change History (11)
comment:1 Changed on Mar 8, 2011 at 6:09:36 PM by dkocher
- Owner set to dkocher
- Status changed from new to assigned
- Summary changed from Single-file upload limitation to Uploading folders fails
comment:2 Changed on Mar 8, 2011 at 6:24:31 PM by dkocher
- Resolution set to fixed
- Status changed from assigned to closed
comment:3 Changed on Mar 8, 2011 at 8:25:22 PM by dkocher
- Milestone changed from 4.1 to 4.0.1
comment:4 follow-up: ↓ 6 Changed on Mar 9, 2011 at 5:20:14 PM by jfingas
- Resolution fixed deleted
- Status changed from closed to reopened
Not fixed. Issue is that the client will not allow dragging and dropping more than one file at a time and has nothing to do, at all, with folders.
No error message.
comment:5 Changed on Mar 10, 2011 at 5:13:15 PM by dkocher
- Type changed from enhancement to defect
comment:6 in reply to: ↑ 4 ; follow-up: ↓ 8 Changed on Mar 10, 2011 at 5:19:25 PM by dkocher
Replying to jfingas:
Not fixed. Issue is that the client will not allow dragging and dropping more than one file at a time and has nothing to do, at all, with folders.
No error message.
Can you give the exact steps to follow to replicate the issue.
comment:7 Changed on Mar 10, 2011 at 5:19:46 PM by dkocher
- Resolution set to fixed
- Status changed from reopened to closed
comment:8 in reply to: ↑ 6 ; follow-up: ↓ 9 Changed on Mar 10, 2011 at 5:36:53 PM by jfingas
It's pretty simple. Any attempt to group select more than one file and drag it into the main file directory window for an upload will only transfer one of the files, usually the first one that was selected. It doesn't matter which files, how many of them are being uploaded, or where they are located on the uploader's computer. These are all small files as well (usually a few dozen kilobytes).
Replying to dkocher:
Replying to jfingas:
Not fixed. Issue is that the client will not allow dragging and dropping more than one file at a time and has nothing to do, at all, with folders.
No error message.
Can you give the exact steps to follow to replicate the issue.
comment:9 in reply to: ↑ 8 ; follow-up: ↓ 10 Changed on Mar 10, 2011 at 5:47:41 PM by dkocher
Replying to jfingas:
It's pretty simple. Any attempt to group select more than one file and drag it into the main file directory window for an upload will only transfer one of the files, usually the first one that was selected. It doesn't matter which files, how many of them are being uploaded, or where they are located on the uploader's computer. These are all small files as well (usually a few dozen kilobytes).
I cannot replicate this issue. Can you find any related output in the system.log (/Applications/Utilities/Console.app)? Also, please post the transcript from the log drawer of the Transfers window.
comment:10 in reply to: ↑ 9 Changed on Mar 10, 2011 at 6:08:30 PM by jfingas
Replying to dkocher:
Replying to jfingas:
It's pretty simple. Any attempt to group select more than one file and drag it into the main file directory window for an upload will only transfer one of the files, usually the first one that was selected. It doesn't matter which files, how many of them are being uploaded, or where they are located on the uploader's computer. These are all small files as well (usually a few dozen kilobytes).
I cannot replicate this issue. Can you find any related output in the system.log (/Applications/Utilities/Console.app)? Also, please post the transcript from the log drawer of the Transfers window.
There doesn't appear to be any smoking gun evidence. Here's the only system.log entries from today (multi-file uploads have been attempted hours later):
Mar 10 06:46:34 Macintosh-2 /Applications/Cyberduck.app/Contents/MacOS/Cyberduck[31091]: MDS Error: unable to create user DBs in /var/folders/Ta/TaI-f+MFHMyIfB+NbzFPJU+++TI/-Caches-//mds Mar 10 06:46:34 Macintosh-2 /Applications/Cyberduck.app/Contents/MacOS/Cyberduck[31091]: MDS Error: unable to create user DBs in /var/folders/Ta/TaI-f+MFHMyIfB+NbzFPJU+++TI/-Caches-//mds Mar 10 06:46:41 Macintosh-2 /Applications/Cyberduck.app/Contents/MacOS/Cyberduck[31091]: MDS Error: unable to create user DBs in /var/folders/Ta/TaI-f+MFHMyIfB+NbzFPJU+++TI/-Caches-//mds
And for reference, the transcript from the transfer log drawer. Note: it only shows the one file being accepted for a transfer despite dragging two files, so clearly the app doesn't seem to know there's even another file being dragged in.
220---------- Welcome to Pure-FTPd [privsep] [TLS] ---------- 220-You are user number 2 of 50 allowed. 220-Local time is now 13:02. Server port: 21. 220-This is a private system - No anonymous login 220 You will be disconnected after 30 minutes of inactivity. USER photos_macnn 331 User photos_macnn OK. Password required PASS ******** 230-User photos_macnn has group access to: nginx 230 OK. Current restricted directory is / FEAT 211-Extensions supported: EPRT IDLE MDTM SIZE REST STREAM MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*; MLSD AUTH TLS PBSZ PROT UTF8 ESTA PASV EPSV SPSV ESTP 211 End. OPTS UTF8 ON 200 OK, UTF-8 enabled NOOP 200 Zzz... SYST 215 UNIX Type: L8 CWD /news/1103 250 OK. Current directory is /news/1103 TYPE A 200 TYPE is now ASCII PASV 227 Entering Passive Mode (207,58,150,179,21,79) MLSD 150 Accepted data connection type=cdir;sizd=36864;modify=20110310175323;UNIX.mode=0776;UNIX.uid=100;UNIX.gid=103;unique=805g1be8ceb; . type=pdir;sizd=4096;modify=20110307025925;UNIX.mode=0777;UNIX.uid=100;UNIX.gid=103;unique=805g1b92046; .. type=file;size=51105;modify=20110310093018;UNIX.mode=0776;UNIX.uid=100;UNIX.gid=103;unique=805g1748a4a; 3ality-605x467.jpg type=file;size=21874;modify=20110310093205;UNIX.mode=0776;UNIX.uid=100;UNIX.gid=103;unique=805g1748a4b; 3ality_gallery.jpg type=file;size=94602;modify=20110310093016;UNIX.mode=0776;UNIX.uid=100;UNIX.gid=103;unique=805g1748a47; 3ality_inline1.jpg 226-Options: -a -l 226 705 matches total TYPE I 200 TYPE is now 8-bit binary PASV 227 Entering Passive Mode (207,58,150,179,22,148) STOR /news/1103/virginamerica.jpg 150 Accepted data connection 226-File successfully transferred 226 0.174 seconds (measured here), 65.10 Kbytes per second NOOP 200 Zzz... SITE CHMOD 644 /news/1103/virginamerica.jpg 200 Permissions changed on /news/1103/virginamerica.jpg QUIT 221-Goodbye. You uploaded 12 and downloaded 0 kbytes. 221 Logout.}}}
comment:11 in reply to: ↑ description Changed on Jan 7, 2012 at 8:27:12 AM by annapurna
Replying to jfingas:
CyberDuck 4.0 introduced an arbitrary limitation where it only allows one file to be sent at a time through drag-and-drop, at least in Mac OS X 10.6.6. This must be fixed to restore multi-file drag-and-drop, since it's a serious step backwards for the entire client.
I am not able to send any folder unless it is zipped even with the transfer button. one file like a Jpeg image works fine.
I tried with FireFtp and no problem.
is it a permission problem or something else?
all the best.
ftp erreur 553 could not create a file
}}}
Hotfix in r8506.