I just installed CoreFTP-lite for the first time, and I am trying to edit a file that is on a host.
I set up my file associations to use notepad.exe for .html files.
When I click on the file and select edt, I do get the file in NotePad.
However, when I save it, I have lost all linefeed and return characters. The html page of course no longer works.
What am I doing wrong? Is there another option that I need to set up?
- David
Problem editing with NotePad [CoreFTP-lite 1.3]
Thanks for the suggestions. Unfortunately, the problem still not solved.
I dug a little deeper. Here is what I know so far.
- I am running under Windows 2000 Pro.
- If I create a text file (.html) on my client with NotePad, and I view it in NotePad, all line spacing appears normal. If I change it, save it, and re-edit it, line spacing is still normal.
- If I use CoreFTP to transfer it to a host, it appears normal when I view it directly on the host (using a host-based text editor).
- If I use CoreFTP to transfer the file back to my client, and then view it in NotePad, line spacing still looks normal.
- If I save it, or "Save As" it, it still looks normal in the original Notepad session.
- If I view the saved file again in NotePad, I have lost all line spacing. Everything is on one line. No line feeds or returns.
When I get time, I will look for a hex editor, so that I can see the real difference between a file that always existed on the client, and one that has made a round trip to the host via CoreFTP.
In the meantime, do you have any other thoughts on this problem?
- David
I dug a little deeper. Here is what I know so far.
- I am running under Windows 2000 Pro.
- If I create a text file (.html) on my client with NotePad, and I view it in NotePad, all line spacing appears normal. If I change it, save it, and re-edit it, line spacing is still normal.
- If I use CoreFTP to transfer it to a host, it appears normal when I view it directly on the host (using a host-based text editor).
- If I use CoreFTP to transfer the file back to my client, and then view it in NotePad, line spacing still looks normal.
- If I save it, or "Save As" it, it still looks normal in the original Notepad session.
- If I view the saved file again in NotePad, I have lost all line spacing. Everything is on one line. No line feeds or returns.
When I get time, I will look for a hex editor, so that I can see the real difference between a file that always existed on the client, and one that has made a round trip to the host via CoreFTP.
In the meantime, do you have any other thoughts on this problem?
- David
Thanks for your efforts and your willingness to help.
I found the culprit.
It is the host-based text editor that is removing CRs. The files only exhibited the NotePad problem if I had saved them at least once directly on the host, using the host-based text editor. Apparently, the CRs are not needed on Unix servers -- only LFs are needed. However Windows needs both.
NotePad displays the file fine with only LFs. However, it discards those LFs when it saves the file, thus rendering the file useless.
So, it seems that I am left with two options: (1) Either find an FTP client that has a Unix => Windows transfer option which adds CRs if needed, or find an editor that handles LFs only. The problem with the latter solution, is that it is easy to forget to avoid NotePad. If you forget once, you destroy the file.
Any suggestions?
- David
I found the culprit.
It is the host-based text editor that is removing CRs. The files only exhibited the NotePad problem if I had saved them at least once directly on the host, using the host-based text editor. Apparently, the CRs are not needed on Unix servers -- only LFs are needed. However Windows needs both.
NotePad displays the file fine with only LFs. However, it discards those LFs when it saves the file, thus rendering the file useless.
So, it seems that I am left with two options: (1) Either find an FTP client that has a Unix => Windows transfer option which adds CRs if needed, or find an editor that handles LFs only. The problem with the latter solution, is that it is easy to forget to avoid NotePad. If you forget once, you destroy the file.
Any suggestions?
- David
CP,
Thanks for your excellent support, especially for a free product!!!
I found a hex editor, so I can now tell you exactly what is going on.
(1) Original file, created in NotePad, contains hex '0d 0a' for new lines.
(2) Original file, transferred to host, viewed via host text editor (but not saved), and transferred back to client, still contains '0d 0a' for new lines.
(3) Original file, transferred to host, viewed via host text editor AND SAVED, and transferred back to client, NOW contains hex '0d 0d 0a' for new lines.
(4) File containing '0d 0d 0a' new line characters, looks ok in NotePad. However, when saved from NotePad, all '0d 0d 0a' sequences are stripped out, leaving NOTHING between lines. I am using Windows 2000 Pro Notepad Ver 5.0.2195 SP4.
Verrrry interesting, hmmmm? The host editor was actually adding a character, rather than removing one.
The host editor, BTW, is whatever Comcast.net supplies to its ISP subscribers for maintaining personal web pages.
I would not even think about modifying CoreFTP to support this type of weirdness. I am just going to have to choose my best workaround. CoreFTP's feature of being able to edit a host file with an automatic round-trip transfer is unique and wonderfully convenient. I love it. Unfortunately, I cannot use it.
I like to do preliminary development client-side, to keep the client and host in sync, and to utilized NotePad's search & replace functions (which are missing in the host-side editor). Once I am running on the host, tweaking code, I could use either NotePad or host editing.
However, when I someone else, elsewhere, does web page maintenance in my absence, it is easier for them to use the host-based editing, which then preps the file for me to destroy it with NotePad. It is all workable, albeit awkward and error prone.
Thanks again for your interest and help.
- David
Thanks for your excellent support, especially for a free product!!!
I found a hex editor, so I can now tell you exactly what is going on.
(1) Original file, created in NotePad, contains hex '0d 0a' for new lines.
(2) Original file, transferred to host, viewed via host text editor (but not saved), and transferred back to client, still contains '0d 0a' for new lines.
(3) Original file, transferred to host, viewed via host text editor AND SAVED, and transferred back to client, NOW contains hex '0d 0d 0a' for new lines.
(4) File containing '0d 0d 0a' new line characters, looks ok in NotePad. However, when saved from NotePad, all '0d 0d 0a' sequences are stripped out, leaving NOTHING between lines. I am using Windows 2000 Pro Notepad Ver 5.0.2195 SP4.
Verrrry interesting, hmmmm? The host editor was actually adding a character, rather than removing one.
The host editor, BTW, is whatever Comcast.net supplies to its ISP subscribers for maintaining personal web pages.
I would not even think about modifying CoreFTP to support this type of weirdness. I am just going to have to choose my best workaround. CoreFTP's feature of being able to edit a host file with an automatic round-trip transfer is unique and wonderfully convenient. I love it. Unfortunately, I cannot use it.
I like to do preliminary development client-side, to keep the client and host in sync, and to utilized NotePad's search & replace functions (which are missing in the host-side editor). Once I am running on the host, tweaking code, I could use either NotePad or host editing.
However, when I someone else, elsewhere, does web page maintenance in my absence, it is easier for them to use the host-based editing, which then preps the file for me to destroy it with NotePad. It is all workable, albeit awkward and error prone.
Thanks again for your interest and help.
- David
ADDITIONAL CONSIDERATIONS:
(1) For completeness of testing, I created a brand new file using the host text editor. I transferred it to my client and viewed it in hex. The line separator is hex '0d 0d 0a'.
(2) If I bring up the web page (the file that we are discussing) via its host URL in a web browser (I.E.), and click "View" => "Source", the file that is displayed in NotePad contains the normal, two-character line seperator, hex '0d 0a'. Both the HTML and the JavaScript portions of the code contain '0d 0a' for line separators. The file is fully editable in NotePad without any corruption resulting.
(3) Because I do not have a host-based hex editor, I do not know for sure whether or not the host editor is actually writing '0d 0d 0a' sequences, or whether it is an artifact of the interaction between whatever the host editor is actually writing, and CoreFTP's ASCII file transfer.
Does this change your thoughts about what might be happening?
- David
(1) For completeness of testing, I created a brand new file using the host text editor. I transferred it to my client and viewed it in hex. The line separator is hex '0d 0d 0a'.
(2) If I bring up the web page (the file that we are discussing) via its host URL in a web browser (I.E.), and click "View" => "Source", the file that is displayed in NotePad contains the normal, two-character line seperator, hex '0d 0a'. Both the HTML and the JavaScript portions of the code contain '0d 0a' for line separators. The file is fully editable in NotePad without any corruption resulting.
(3) Because I do not have a host-based hex editor, I do not know for sure whether or not the host editor is actually writing '0d 0d 0a' sequences, or whether it is an artifact of the interaction between whatever the host editor is actually writing, and CoreFTP's ASCII file transfer.
Does this change your thoughts about what might be happening?
- David
CP,
I just tried the binary transfer test. Files created with the host editor come across with a hex '0d 0a' sequence.
Therefore, it appears that the ascii transfer is
converting '0d 0a' to '0d 0d 0a'.
I can only speculate why they might be implementing it as such. Perhaps it is so that a Window-based browser's "View Source" feature will display correctly. Perhaps I am wrong about its being a Unix server; maybe it's a Windows server. I will try to find out from a Comcast tech (assuming that I can get past their front-line support). I will let you know what I find out.
My solution to editing appears to be to use a binary transfer.
Thanks for all your assistance in this matter.
I just tried the binary transfer test. Files created with the host editor come across with a hex '0d 0a' sequence.
Therefore, it appears that the ascii transfer is
converting '0d 0a' to '0d 0d 0a'.
I can only speculate why they might be implementing it as such. Perhaps it is so that a Window-based browser's "View Source" feature will display correctly. Perhaps I am wrong about its being a Unix server; maybe it's a Windows server. I will try to find out from a Comcast tech (assuming that I can get past their front-line support). I will let you know what I find out.
My solution to editing appears to be to use a binary transfer.
Thanks for all your assistance in this matter.
CP,
If I create a file with the host editor, and transfer it from the host to my client workstation in BINARY mode, the line delimiter sequence is hex '0d 0a'. That is the correct newline sequence, because the host (per Comcast customer support) is Windows rather than Unix.
If I transfer the exact same file from the host to my client workstation in ASCII mode, the line delimiter sequence becomes hex '0d 0d 0a' in the file on my workstation.
Could CoreFTP be having trouble recognizing that this particular host is a Windows server? Alternatively, might I have been given incorrect information from Comcast regarding the host OS?
Would you like me to email the transmission log to you?
- David
If I create a file with the host editor, and transfer it from the host to my client workstation in BINARY mode, the line delimiter sequence is hex '0d 0a'. That is the correct newline sequence, because the host (per Comcast customer support) is Windows rather than Unix.
If I transfer the exact same file from the host to my client workstation in ASCII mode, the line delimiter sequence becomes hex '0d 0d 0a' in the file on my workstation.
Could CoreFTP be having trouble recognizing that this particular host is a Windows server? Alternatively, might I have been given incorrect information from Comcast regarding the host OS?
Would you like me to email the transmission log to you?
- David
I used the tool at netcraft.com to check on my server's OS. According to that utility, home.comcast.net is running "Solaris 8".
As I mentioned previously, binary transfers work fine in both direction, even if the file is edited on the server with the host-based text editor, and/or on my workstation with NotePad.
As you suggested much earlier, the problem seems to be the confusion caused by a Windows newline convention's being used on a Unix server. I asked Comcast to dig further into this issue, and I am awaiting their call back.
- David
As I mentioned previously, binary transfers work fine in both direction, even if the file is edited on the server with the host-based text editor, and/or on my workstation with NotePad.
As you suggested much earlier, the problem seems to be the confusion caused by a Windows newline convention's being used on a Unix server. I asked Comcast to dig further into this issue, and I am awaiting their call back.
- David