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

FTPS switches to ascii mode in CLI #11519

Closed
cyberduck opened this issue Dec 29, 2020 · 5 comments
Closed

FTPS switches to ascii mode in CLI #11519

cyberduck opened this issue Dec 29, 2020 · 5 comments
Labels
bug cli Command Line Interface worksforme

Comments

@cyberduck
Copy link
Collaborator

b6381f1 created the issue

I'm using a script to upload some files if they have been updated locally. I just noticed that duck is switching to ASCII mode when it's uploading a text file. This of course wreaks havoc with the unicode files. Here's the verbose output of the command:

~/ >duck -v -r 4 -y -e upload --synchronize "ftps://user@server.org/public_html/dirname/file.html" "$src/file.html"
Login successful…
> CWD /public_html/dirname
< 250 OK. Current directory is /public_html/dirname
> TYPE A
< 200 TYPE is now ASCII
@cyberduck
Copy link
Collaborator Author

b6381f1 commented

I should note that I don't see this behavior with a couple of other files. They have "json" and "ttl" extensions.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Can you provide the full log output. We may issue TYPE A prior a STAT, MLSD or LIST command but should revert to binary mode with TYPE I prior a file transfer.

@cyberduck
Copy link
Collaborator Author

b6381f1 commented

Here's the full output when I run the command with the two files definitely not identical.

Login successful…
> CWD /public_html/temples
< 250 OK. Current directory is /public_html/temples
> TYPE A
< 200 TYPE is now ASCII
> PRET MLSD null
< 200 Ready to proceed
> PASV
< 227 Entering Passive Mode (142,93,240,16,174,137)
> MLSD
< 150 Accepted data connection
< type=pdir;sizd=4096;modify=20210124011013;UNIX.mode=0750;UNIX.uid=1273;UNIX.gid=99;unique=800g7c0202; ..
< type=file;size=1639;modify=20210124161059;UNIX.mode=0664;UNIX.uid=1273;UNIX.gid=1275;unique=800g8002c6; temple_bib_general.html
< type=file;size=1834;modify=20210110234804;UNIX.mode=0644;UNIX.uid=1273;UNIX.gid=1275;unique=800g8012fe; temple_bib_general2.html
< type=cdir;sizd=4096;modify=20210124161045;UNIX.mode=0755;UNIX.uid=1273;UNIX.gid=1275;unique=800g8010a9; .
Transfer incomplete. temple_bib_general.html ↔ gen_temple_bib.html…
> QUIT
< 221-Goodbye. You uploaded 0 and downloaded 0 kbytes.
221 Logout.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

The above output suggests no transfer is made because the file is considered identical. Try using --existing overwrite --upload instead.

@cyberduck
Copy link
Collaborator Author

b6381f1 commented

Replying to [comment:4 dkocher]:

The above output suggests no transfer is made because the file is considered identical. Try using --existing overwrite --upload instead.

OK, the problem seems to have been that the --retry option no longer takes a argument and I had a "4" in there. It was causing erratic behavior on several uploads, though pretty steadily working for several of them.

The command structure seems to have changed within the past 15 months or so, though I can't find a reference to it in the changelog.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug cli Command Line Interface worksforme
Projects
None yet
Development

No branches or pull requests

1 participant