Go Back   FlashFXP Forums > >

General Discussion Need help? Have a problem? Let us help you. Bug reports and feature requests should be made using the Bug Tracker or Feature Tracker

Closed Thread
Thread Tools Rate Thread Display Modes
Old 12-20-2013, 05:40 PM   #16
Junior Member
FlashFXP Registered User
DJAndre's Avatar
Join Date: Mar 2004
Location: San Diego, CA
Posts: 12

Originally Posted by X3 View Post
ffxp never changes line endings for anything unless your 3rd party apps do it. either it was you or someone else but fro what I gather it wasnt ffxp. ;>
With all due respect, that is not what was hashed out in this help topic. IMHO, you should spend some time reading it thoroughly, because what you just stated is wrong and it later causes misinformation and misunderstandings going forward.

If FFXP's Transfer Mode is set to Auto and PHP files are in the ASCII filter (as well as other types of files), it will change "line endings" from a LINUX server to a Windows PC transfer if the files have specific formats (i.e. UNIX).

The solution was to switch Transfer Mode to BINARY. Which will stop FFXP to make changes to certain files--according to it's ASCII filter settings.

My previous post was for me to have a clear understanding for the purpose for ASCII transfer mode. I just need someone to verify if that is what it's meant for--in layman terms. Because I really don't see another reason for it's purpose, especially since it will cause these kinds of issues for us that require certain files to be a specific format.

Before, I was relying on different methods to download a file for me to edit or work on, so it could keep it's original formatting. Since FFXP was giving me odd results, I was deterred in using this app. Now that I've come forward and asked the experts here, I was finally given a setting I can work with, and I am much more happier, since this will help me immensely with efficiency in tackling these tasks going forward.
My System Info:

App: FlashFXP 4.4.3 (build 2029) [registered]
OS: WinXP Pro
Router: Linksys WRT54G build 5
Firewall: COMODO
Anti-Virus: AVAST
Network: Broadband
ISP: cox.net
DJAndre is offline  
Old 12-21-2013, 08:59 AM   #17
Senior Member
FlashFXP Beta Tester
X3's Avatar
Join Date: Feb 2006
Location: location, location.
Posts: 324

I use Linux servers daily and have similar uses for unix line endings just like you, in fact my files are all unix style line endings, and auto mode never done any of this for me in ffxp and I also use notepad++, I do not use binary exclusively in ffxp.

I also read this topic and been following it from beginning, and your reaction just makes me wonder. My reply is purely because;
My ffxp settings are auto and checked [x] use smart mode handling when auto is selected. What I feel odd is that you has a problem and I do not with exact similar file formatting.
However my files are created in Linux via ssh and nano.


Actually I just noticed that notepad++ by default my file creation is unix line endings I create a test.php or test.whatever and it automatically dos/windows and no matter what it never saves that file with unix line endings even after changing it it manually. That is both locally and remotely via windows or ffxp.

So here it is, notepad++ alone and no ffxp in sight bingo. But that's just my findings.

Last edited by X3; 12-21-2013 at 09:29 AM.
X3 is offline  
Old 12-21-2013, 09:21 AM   #18
FlashFXP Developer
FlashFXP Administrator
ioFTPD Beta Tester
bigstar's Avatar
Join Date: Oct 2001
Posts: 8,012

Originally Posted by DJAndre View Post
Just to give summary, the reason for ASCII is to convert txt based files so we could open them in our OS apps and they all don't appear like one horizontal line of code, so it's formatted so our txt based readers can view them with proper "returns".

And since I use Notepad++ and not Notepad that comes default for Windows, I would not need for these txt based files to be converted, since I use that app.

Am I correct with my assumption for the purpose of such setting?
Yes that is 100% correct and is perfectly fine for your specific situation.
bigstar is offline  
Old 12-21-2013, 09:40 AM   #19
FlashFXP Developer
FlashFXP Administrator
ioFTPD Beta Tester
bigstar's Avatar
Join Date: Oct 2001
Posts: 8,012

After this long winded thread I thought it would make sense to add a re-cap.

  • When using ASCII transfer mode the file EOL (end of line) characters are swapped by the FTP server. If the FTP server is UNIX then CR is typically swapped to CR/LF, depending on the FTP server software and the way it is configured, in some configurations switching to ASCII mode may not actually do any conversion at all.
  • Some UNIX based FTP servers have been known to mangle the EOL characters especially when the file content doesn't use the UNIX style EOL character, if the remote file is Windows formatted EOL then it could result in replacing CR/LF with CR/CR/LF.
  • Resuming files transferred in ASCII mode can lead to corruption due to the way the EOL characters are handled and converted by the FTP server.
  • If you're using a text editor such as NotePad++ then using ASCII mode is not necessary and you may have better results using BINARY mode for everything.
  • The only time ASCII mode might be necessary is if you're transferring configuration files between a FTP server running on UNIX (or other) to WINDOWS for use with some software that requires the EOL to be specific to the operating system.
  • It is becoming more and more common for FTP servers to use BINARY mode for everything.
  • When transferring files using the SFTP over SSH protocol FlashFXP will always transfer the file in BINARY mode.
bigstar is offline  
Closed Thread

download, flashfxp, ftp, set, upload

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT -5. The time now is 09:29 PM.

Parts of this site powered by vBulletin Mods & Addons from DragonByte Technologies Ltd. (Details)