Hotfix in r8506.

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.

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.

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.

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.

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.}}}

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

}}}