Something a bit strange has just been suggested to me, that the ftp program I use to upload files to the server creates empty lines or rows in a document. I was therefore asked to revise my client settings, but I wasn't really aware that the ftp program would alter anything specific in a document when uploading (quite another thing is of course the fact that the document may not fully upload and therefore some content is broken).

Has anyone heard of anything like this?

I mean, I have looked at the document and there's a blank line in between every line of code. So instead of being a 500 line document, it is now 1000 lines. A bit tedious to remove all the blank lines by hand...

Are you using the same text editor to view the files?

In the past I have found that a handful of text editors can render pages differently.

What ftp client are you using to upload the files? An ftp client should transfer a copy of the file on your computer to the web server. No changes should be made.

jason, exactly, that was what I thought as well, so I couldn't really understand why anyone's so sure it's my ftp causing the problem.

The scenario is this: I use SmartFTP (v3), which should be decent enough, to upload/fetch files, or from within Dreamweaver (CS3). I use DWCS3 to edit/read files, as well as notepad++. All on Windows Vista. The programmer uses WS_Ftp (http://www.wsftp.com/) to upload/fetch files, and his editor/reader is Dreamweaver MX2004. He's on XP.

The last couple of times I've received complaints I've been using SmartFTP to upload files. Why the programmer thinks my ftp software is the culprit...

Could you upload a file an affected file, make it something simple and unimportant. Then pm the link. I will open it. If I get double lines then the problems on your end. If I get single lines the problems on the other guys end.

EDIT: Have you checked your Dreamweaver save preferences. I think there is a double line option. I am not sure though, been ages since I fired it up.

Jason, thanks for offering to help. I think I have the solution, though. I checked with the author of SmartFTP (at least I think that is the person responding on the SmartFTP forum) and he was quite certain it was not a problem with the ftp software. He added "make sure you upload files in binary mode." So it struck me this was the problem. I then checked with the programmer in what mode I need to upload the files, and he said "ascii." I did a test where I uploaded the same file in ascii mode and the blank lines did not appear.

These are template files for a cms and combine the use of php scripts, javascripts and html. I always use "auto" mode so I have never occupied myself with learning about when to use binary or ascii mode and to date I haven't run into any problems. However, it seems in this case that the ftp program is using binary mode to send these files when apparently they should be sent in ascii mode.

I can still use auto mode and create specific exceptions for file types like .php etc specific to every ftp account.

Curiously, the problem with blank lines does not occur when uploading with DW, which then seems to be making the "correct" choices about binary and ascii mode.

Different operating systems use different characters at the end of a line.

Linux/Unix uses LF (line feed), Mac's traditionally use CR (carriage return) and Windows use CR-LF (or is it LF-CR).

Transferring files in ASCII mode will generally substitute the line ending characters based on the OS of the destination (as advertised by the FTP server). Binary does not change the file at all. Because windows uses two characters at the end of a line, if you edit that file on another OS you'll see double lines.

The thing here could be that I'm editing on Windows and the server is Unix based. But that has never caused me any problems before. The file is not edited on the server.

I don't know, it seems to work when I upload in ascii mode, so I will stick to that for these files. They will kill me otherwise. The last php file had about 2500 lines when it should only have 250. The programmer went ballistic...