FILE_WRITE adds extra carriage return CR

ijed

Stumped by this one:

Trying to just write out the response from an IP port to a local file on the NI4100.

so I open a file:

_slFileHandle = FILE_OPEN(cLocalFile, FILE_RW_NEW)

anything coming in I write to the file:

DATA_EVENT [dvDATAPORT]
{
	STRING:
	{
		local_var long nBytes
		nBytes = length_array(cFTPServerBuffer)
		FILE_WRITE(_slFileHandle, get_buffer_string(cFTPServerBuffer, nBytes), nBytes)			
	}
}

then when transfer is complete I close the file


what I see is everytime there is a CR it's being replaced by 2 CRs

I tried writing out a line at a time:

		while(find_string(cFTPServerBuffer, "13, 10", 1))
		{
			cTemp = remove_string(cFTPServerBuffer, "13, 10", 1)
			nBytes = length_array(cTemp)
			//SEND_STRING dvDebug, cTemp
			FILE_WRITE(_slFileHandle, cTemp, nBytes)
		}

or even stripping off any CRLFs and using FILE_WRITE_LINE but it makes no difference

the strings are fine coming in too - but when I look at what's saved I see 2 0D's when there should be 1.

Funny thing is notepad doesn't seem to mind this - but when I open it in Notepad++ I get a space between each line and in HexViewer I see the offending 0D

nicholasjames

Could it be your FTP client? I've had issues in the past with some clients & AMX's FTP.

HARMAN_icraigie

nicholasjames wrote: »

Could it be your FTP client? I've had issues in the past with some clients & AMX's FTP.

Not exlusivey an AMX issue. Check to see if the ftp client has been set to asciii or binary mode. Try uploading in the other mode - or set it to auto and forget about it.

ijed

nicholasjames wrote: »

Could it be your FTP client? I've had issues in the past with some clients & AMX's FTP.

icraigie wrote: »

Not exlusivey an AMX issue. Check to see if the ftp client has been set to asciii or binary mode. Try uploading in the other mode - or set it to auto and forget about it.

Using Windows 2008 NT FTP Server - NI is just sending commands on one port and sending/retrieving data on another.

Just tried both TYPE A and TYPE I transfer modes with no success

SYST command doesn't give a default type (Just says Windows_NT) and google's not helping me find anyway to change any settings (only options I get are to change directory listings in MS-DOS or UNIX format)...

The weird thing is the buffer looks fine though - it's not until I write the file that it puts in the extra $0D

Line      9 (10:56:09)::  <session name="Test Session 01" exams="16">$0D$0A
Line     10 (10:56:09)::  $09$09<preroll chime="1" duration="72"/>$0D$0A
Line     11 (10:56:09)::  $09$09<reading chime="2" duration="125"/>$0D$0A

It actually looks like it's converting a $0A to a $0D$0A

if I take out the $0D before writing the file:

	cTemp = remove_string(cFTPServerBuffer, "13, 10", 1)
	cTemp = left_string(cTemp, length_array(cTemp)-2)
	cTemp = "cTemp, 10"
	nBytes = length_array(cTemp)
	FILE_WRITE(_slFileHandle, cTemp, nBytes)

now looks like this:

Line      9 (11:38:12)::  <session name="Test Session 01" exams="16">$0A
Line     10 (11:38:12)::  $09$09<preroll chime="1" duration="72"/>$0A

and writes it out like this, putting the $0Ds back in:

3C73657373696F6E206E616D653D2254
6573742053657373696F6E2030312220
6578616D733D223136223E[B]0D0A[/B]09093C
707265726F6C6C206368696D653D2231
22206475726174696F6E3D223732222F
3E[B]0D0A[/B]

Further tests
Arg - so the original file only has a $0D (no $0A) so FTP Server is adding a $0A then FILE_WRITE seems to be adding another $0D ? Now I'm really confused

Joe Hebert

ijed wrote: »

FILE_WRITE adds extra carriage return CR

what I see is everytime there is a CR it's being replaced by 2 CRs

I performed several different tests (on an NI-700) and I couldn’t find one case where FILE_WRITE is adding an extra CR. FILE_WRITE is working perfectly as far as I can tell.

Have you tried eliminating your FTP client from the equation? After you write the file, read the file back in and print the contents to the screen.

If you are still having problems please post code that demonstrates your FILE_WRITE issue so we can try it out for ourselves.

ijed

Joe Hebert wrote: »

I performed several different tests (on an NI-700) and I couldn’t find one case where FILE_WRITE is adding an extra CR. FILE_WRITE is working perfectly as far as I can tell.

Have you tried eliminating your FTP client from the equation? After you write the file, read the file back in and print the contents to the screen.

If you are still having problems please post code that demonstrates your FILE_WRITE issue so we can try it out for ourselves.

One of the IT guys came in to have a look at it - turned off using FTP via SSL and it all started behaving.

Thanks for the help