What happened to the hard returns in my text file?

We're running WinSCP on a 64-bit Windows DataCenter Server and it has never worked correctly even once since the day the system admins installed it. The problem is the file transfer itself, which seems to strip the hard returns out of every text file it transports. Ironically, 4 of the 5 text files are still being successfully imported by SSIS. The fifth file is the largest of them all and also the one that won't import. If I copy the file instead of SFTP it, SSIS imports it just fine.

My biggest source of confusion: if I copy the files down to my desktop and open them there, the hard returns don't appear to have gone anywhere!

Why does one of my text files get rename to "file1.txt.filepart"? Why can't it be renamed back?

Thanks,
Eric

What is "hard return"?
Anyway, if want WinSCP to transfer file as is, please make sure you are using binary transfer mode:
https://winscp.net/eng/docs/transfer_mode

.filepart are temporary files being used while uploading large files.
Please read:
https://winscp.net/eng/docs/resume#automatic

Do I understand right that after the transfer, the .filepart extension does not get stripped?
If that's true, you should be getting some error message. What is it?

Hi Prikryl,

By "hard return," I mean that it appears as though all rows of text in my text file have become one single row. I've opened the text files (the original file from the source server and the SFTP'd file on the SFTP server) in Notepad++ in order to Show All Characters so I can compare the two and here's what I see:

the original file has two characters after the last text character on each line: one is "CR", the next is "LF"

the SFTP'd file has one character after the last text character on each line: "CR"

So my problem is [it appears] every text file is getting the Carriage Return characters stripped out. I am going to read those pages linked that you suggested.

The WinSCP.exe log file that gets created every time my client machine sends the files includes "Sending special code: 12" right before "ERROR: SFTPPush FAILED." The last line of the AWE log on the SFTP server reports "TASKSUCCESS,6,Task ended." Is there somewhere else I can find an error message?

As far as .filepart extensions: I only have that problem with one of my text files. The other text files get transferred successfully with no carriage returns stripped out, but whatever problem is causing the .filepart extension to persist causes the SFTP upload to immediately fail, so files that occur later alphabetically do not get transferred.

Again, I will try the links you suggested. Thanks for your help.

Prikryl,

I've tried binary mode and this certainly does not strip out the carriage returns, but I do have the ".filepart" extension problem as well as the remaining files that do not get uploaded because their file names are alphabetically after the 4th file that gets the .filepart extension. Automatic Resume is enabled, although I don't think that my file transfers are being interrupted. The WinSCP log on the SFTP server only includes a lot of text, but the only error message I can see is "Sending special code: 12"

It seems like I've tried every configuration combination I could think of, as well as those hinted at by the help pages, but I'm still getting a ".filepart" extension to one of my files and I don't know why.

The page Transfer Modes is a little confusing. It states, "There are two options how to support text mode transfers," but the two options are not clarified. I was looking for "check this for that option, check the other for the other option," but all I see is "The second option is more universal, but it is supported only by SFTP-4 and newer and FTP1)," and "the first option is used by WinSCP for SCP and SFTP-3 and older protocols," but none of this helps me understand which config changes need to be made in order to ensure text files are copied as-is.

I removed "option batch on" from our sftp command text file and I see that I'm prompted for confirmations. With this, I was successful in getting the remaining files to get SFTP'd, but the file with ".filepart" file extension does not get fixed.

--------------------
Transfer was successfully finished, but temporary transfer file 'myfilename.txt.filepart' could not be renamed to target file name 'myfilename.txt'. If the problem persists, you may try to turn off transfer resume support.
No such file or directory.
Error code: 2
Error message from server <en>: File not found
Request code: 18
(A)bort, (R)etry, (S)kip all:
--------------------

Choosing "Retry" gets the same error message over and over. Choosing "Skip all" gets the remaining files uploaded, but does not remove the .filepart file extension.

Am I closer? The login that AWE uses has full permissions on the folder the files are being copied to, so I don't understand why it's unable to rename a file it just created.

Thanks for your help,
Eric

Thanks,
Eric

freedom_nut wrote:

Am I closer? The login that AWE uses has full permissions on the folder the files are being copied to, so I don't understand why it's unable to rename a file it just created.

Neither I do. To try disabling the transfer resume feature altogether.

For transfer mode: Stripping the LF is generally what the text transfer mode should do. At least as long as the server is unix-based. If not, make sure you select the correct line ending option on login dialog. Or just force the binary transfer mode (particularly if server is Windows-based, there's no need for text-transfer mode.

Read more about the error:
https://winscp.net/eng/docs/message_transfer_finished_could_not_rename