Cyberduck Mountain Duck CLI

#11519 closed defect (worksforme)

FTPS switches to ascii mode in CLI

Reported by: eponymous Owned by:
Priority: normal Milestone:
Component: cli Version: 7.7.2
Severity: normal Keywords:
Cc: Architecture: Intel
Platform: macOS 10.15

Description

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

Change History (5)

comment:1 Changed on Jan 11, 2021 at 2:56:59 PM by eponymous

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

comment:2 Changed on Jan 24, 2021 at 3:39:23 PM by dkocher

  • Resolution set to worksforme
  • Status changed from new to closed

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.

comment:3 Changed on Jan 24, 2021 at 4:03:51 PM by eponymous

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.
Last edited on Jan 24, 2021 at 4:12:19 PM by eponymous (previous) (diff)

comment:4 follow-up: Changed on Jan 24, 2021 at 7:08:50 PM by dkocher

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

comment:5 in reply to: ↑ 4 Changed on Jan 24, 2021 at 9:33:39 PM by eponymous

Replying to 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.

Note: See TracTickets for help on using tickets.