Opened 14 years ago

Closed 11 years ago

Last modified 10 years ago

#5195 closed Bug report (outdated)

Intermittent error transferring ASCII file as binary with transfer type set to Auto

Reported by: Kevin Fegan Owned by:
Priority: normal Component: FileZilla Client
Keywords: error transferring ASCII file binary Cc: kevinf2002@…
Component version: Operating system type: Windows
Operating system version: XP-SP3

Description

I am running the most recent version of FileZilla:
Version 3.3.1.
Additional Client info is below (bottom).

I was transferring an ASCII file from my computer (WinXP) to a server (Linux). I noticed the file-size of both files (source and dest) was identical, which seemed odd. So, I verified the settings (below), and I deleted the destination file, and repeated the file transfer with the same outcome. The file-size on the client and the server was 1070 bytes.

Settings->Transfers->Filetypes->Default transfer type: Auto
Settings->Transfers->Filetypes->Automatic file type classification: (list of file-types including txt)

Filename: abc.txt
File abc.txt: 47 lines
File abc.txt: 1070 bytes (DOS)

Then I changed the transfer type setting to BINARY, and I deleted the destination file, and repeated the file transfer. The file was written on the server with an identical file-size (as expected).

Then I changed the transfer type setting to ASCII, and I deleted the destination file, and repeated the file transfer. This time, the file written on the server with a smaller file-size (also, as expected). The file-size on the server was now 1023 bytes.

Finally I changed the transfer type setting back to original setting of Auto, and I deleted the destination file, and repeated the file transfer. This time, the file was written on the server with an smaller file-size (as expected). At this point, everything appeared to be working correctly, but the original failure and failed retry are unexplained.

Kevin

FileZilla Client


Version: 3.3.1

Build information:

Compiled for: i586-pc-mingw32msvc
Compiled on: x86_64-unknown-linux-gnu
Build date: 2010-01-03
Compiled with: i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2)
Compiler flags: -g -O2 -Wall -g -fexceptions

Linked against:

wxWidgets: 2.8.10
GnuTLS: 2.8.3

Change History (8)

in reply to:  description comment:1 by Kevin Fegan, 14 years ago

Replying to kevin:

Sorry, adding additional info:
I clicked the button to "Refresh the file and folder lists" in-between the original attempt and the failed retry.

comment:2 by Tim Kosse, 14 years ago

Status: newmoreinfo

Which server product are you using?

Can you please attach a log of a transfer that comes up using the wrong type?

comment:3 by Kevin Fegan, 14 years ago

Status: moreinfonew

Hi codesquid,

I am not using server product. I am using FileZilla Client 3.3.1 as mentioned in original ticket (now running FileZilla Client v3.3.2).

My web-host is HostGator, they use FTP server:
220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------

I'm not sure if I have access to the server FTPd logs.

Do you want FTP server log? or client log?

I did not notice it from the log and I did not have client logging turned on. I noticed it from viewing the source and destination file size of an ASCII (.txt) file after an upload to my web-host server.

The file size on DOS/Win was 1070 bytes and should have been 1023 bytes on the server.

After the first transfer I noticed that the source and destination file sizes were the same which meant the transfer happened as BINARY. Then I: (1) checked that the transfer type was set to auto, (2) checked that "txt" files were listed as ASCII file (3) clicked the button to "Refresh the file and folder lists", this had no effect, file still showed as 1070 bytes (4) deleted the destination file (5) re-tried the transfer which also ended in binary transfer. I changed the transfer type setting to BINARY and ASCII which both worked fine. Finally I returned the setting to AUTO and repeated the transfer which succeeded. Further transfers appeared to work correctly.

Error is intermittent... If I am able to find a way to cause the error to repeat or if I notice the error and can turn on client logging, I will report back with the logs.

Kevin

comment:4 by Tim Kosse, 14 years ago

Status: newmoreinfo

A client log will suffice for now.

comment:5 by Tim Kosse, 14 years ago

By the way, do you have resume of ASCII transfers enabled in the settings dialog? ASCII type transfers generally cannot be resumed reliably, so should you have enabled it, disable it, that might solve the issue.

in reply to:  5 comment:6 by Kevin Fegan, 14 years ago

Status: moreinfonew

Replying to codesquid:

By the way, do you have resume of ASCII transfers enabled in the settings dialog? ...


I checked this setting and it was already disabled (unchecked).

I'll keep checking and let you know if it happens again. Thanks.

comment:7 by Alexander Schuch, 11 years ago

Status: newmoreinfo

Did you encounter the problem ever again?

comment:8 by Alexander Schuch, 11 years ago

Resolution: outdated
Status: moreinfoclosed

No reply for more than 28 days.

Note: See TracTickets for help on using tickets.