Editing Talk:Data Type

I cannot (at least I dot know how) to upload text-file as a binary one. As result, the text files come to server corrupted. Indeed I was forced to reject from FileZilla for this type of uploading and use another tool. The FZ has to resolve this task.

== Data Type recognition ==

It is time to abandon the File Extension as a data type identifier.  I would propose that the program examine the data file prior to transmission to see what kind of file it is and what set up is needed to send the file correctly to the destina

In these cases the file should be converted to a standard format (Text) and transmitted to the destination as a valid Text file. on the destination.
*<nowiki>*NIX text file</nowiki>
*Windows/DOS text file
*Apple text file
<br>
IN these cases, the file should be sent in binary form.
*Images, compressed files and other binary data streams.

I deal with a lot of data files on a regular basis.  I need to be able to make sure the file arrives as a valid data file on the destination.
<br>
Under present conditions, I have a program that I pre-process files with to make sure they are the correct data format.
 --[[User:Randyrls|Randy Smith aka Randyrls]] 12:57, 16 March 2010 (UTC)

== Unable to transfer Unix text file to Windows with correct line end ==

I have followed the directions given for setting the Data Type to either Auto, ASCII, or Binary. However, regardless of the setting I use, when downloading a text file from a Linux server to a Windows client, the ASCII conversion is not done. The files all come over with just the (LF) Line Feed character, rather than LF-CR (Carriage Return), which Windows uses.

I can transfer a text file from the Windows client to the Linux server and it correctly removes the CR when in ASCII data type, but it does not add it back to the file when downloading.

I need to know how to get this to work correctly, or use another file transfer program, as I have a piece of software on Windows that will not read these files without the correct Windows end of line.

Please help
-------------------------------------

Same problem here. Used to work fine in transfers between Windows and Linux, but as of a couple years ago (at least), Filezilla won't add the CR to line endings with viewing a server file or downloading a server file to Windows.  I've had to resort to to using Notepad++ for all ascii files, which is a pain. (Nice program, but needlessly complicated for most quick edits.)  Yes, FZ is configured to transfer text files as ascii rather than binary.  My default setting is auto, but I have a long list of ASCII file types.   [[User:Zobo|Zobo]] ([[User talk:Zobo|talk]]) 09:35, 15 January 2018 (CET)

UPDATE/CORRECTION??  I downloaded my files from server (Linux Apache shared server at GoDaddy), as a backup, and resulting line endings were just LFs.  I copied them all to a bottom-level folder, and using Notepad++ I replaced all LF endings in all its files and subfolders with CRLF.  Notepadd++ reported changing only a relatively few files, but I took that to mean folders, since all the file types I specified in my filter now end with CRLF.  But, oddly, so do all other ASCII files I've spot checked, all of which were problematic before this operation.  FileZilla is also showing them as CRLF on my computer now.  Yet viewing the (unchanged) files on the server, those still just have LF (unix) endings.  Go figure.  Well, if somehow FZ or Windows got the desired religion, I'm not complaining. Will come back if the "fix" doesn't stick.  [[User:Zobo|Zobo]] ([[User talk:Zobo|talk]]) 10:07, 15 January 2018 (CET)