Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uploading folders fails #5749

Closed
cyberduck opened this issue Mar 8, 2011 · 7 comments
Closed

Uploading folders fails #5749

cyberduck opened this issue Mar 8, 2011 · 7 comments

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented Mar 8, 2011

8118f7a created the issue

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 8, 2011

@dkocher commented

Hotfix in 574d3e5.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 9, 2011

8118f7a commented

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.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 10, 2011

@dkocher commented

Replying to [comment:4 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.

Loading

@cyberduck cyberduck closed this Mar 10, 2011
@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 10, 2011

8118f7a commented

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 [comment:6 dkocher]:

Replying to [comment:4 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.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 10, 2011

@dkocher commented

Replying to [comment:8 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.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 10, 2011

8118f7a commented

Replying to [comment:9 dkocher]:

Replying to [comment:8 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.```

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Jan 7, 2012

3c3fa21 commented

Replying to [5749 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

}}}

Loading

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants