I realise there is a lot of largely irrelevant business logic in my code snippet, but at this point having been stuck with this problem since yesterday & read everything I can find on the subject, on the net this forum & others, not to mention written dozens of variations on this code; I guessing it might be something else I'm missing outside the scope of what I'd consider relevant. With this in mind I should mention that the file created contains all the correct data, it is only the new line characters that seem to be the cause of the problem.
The code builds a file on a linux server & then emails it as an attachment or list of attachments. The file is then downloaded from the email to a windows machine & imported into another application.
The file spec for this import file says lines must end with the carriage return (CR) and line feed (LF), which I never imagined would be an issue; but obviously I am ignorant of some low level detail that is causing this problem.
I discovered that if the file displays correctly in notepad then it imports into this other application correctly.
So I'm using notepad as a test.
Still it's a mission even if I run notepad in WINE on my ubuntu machine, the file displays correctly with line breaks and all aligned.
I tried simply adding \r\n to the string first. Then I've even tried replacing it later as in the example bellow. I tried different encodings & even constructing the email without saving to a file on the server first all to no avail. I've tried using bytes instead of strings hoping for more control.
I really don't understand why it's not working, an suggestions would be helpful. (For a bit of code I expected to take 10min to write, the fact that I'm still stumpted a day later is really.. driving me crazy )
The file saved on the server is then correct (CRLF line separators) but the one that arrives as the attachment to the email is wrong again. If I use "\r\n" instead of newLine() even the saved on the server is incorrect, that is to say the lines end in LF not the desired CRLF.
The getBytesFromFile method that reads the file after run.exec("unix2dos "+fileStorePath+fileName); has updated it somehow causes the CRLF line separators to be lost, which indicates there is something weird happening.
If I can figure out why the CRLF line separators are not coming through in the email attachment it's probably shed some light on the original problem, hopefully making the use of run.exec("unix2dos "+fileStorePath+fileName); unnecessary. It must have something to do with the encoding or something.
Try calling System.setProperty("line.separator", "\r\n") at the start of the application. It's quite possible that some code reads line by line and then uses the system line separator to paste them back together. By changing the system line separator you may be able to prevent this.
And don't worry about changing the backing system; that method call will only change the system line separator inside that one single JVM invocation, not outside of it.
Actually it looks like I got confused/frustrated in my testing, using "\r\n" does seem to product the right file on disk, with no need to call the native script, but once emailed as an attachment looses that CRLF.