ESP8266 Community Forum

Hello everyone

First time posting on this forum, hopefully not violating any netiquette

I'm using the eclipse windows framework by CHERTS and the esphttpd project as base for my webserver project. At the moment heatshrink is also enabled.
I observed some problems with reading (web) files from the espfs filesystem with espFsRead(), probably caused by different interpretation of the linefeed. My html files generated on windows use CR+LF as default for a new line.
Now the thing is espFsRead returns the the data length as I would expect: with CR+LF as 2 characters, in the data though there is only 1 character left (LF), but the length of the data string is still like with 2 characters. Unfortunately that causes additional junk characters at the end of the string.

I suspect the encoding/decoding process of heatshrink to cause this, but I am not completely sure. How should I deal with that? Can i define a flag somewhere for that case? Like a binary mode (was already looking for O_BINARY, but haven't found a solution in that case) or a config define in heatshrink?

I wouldn't mind at all if the read/decompressed data use LF as newline, but then at least I would suspect the returned length to be correct and/or the the string to be terminated at the correct position...

To be honest I have the feeling to overlook something trivial, as others would have had the same behaviour, but i couldn't find anything

Of course I could change the EOL settings in Notepad++ (already tested and it works) but i would prefer a universal windows compliant solution

I found out that it most probably isn't caused through heatshrink, as there is the same behaviour when heatshrink isn't enabled/used.

At this point I suspect the problem to be in the filesystem generation. Maybe Sprite_tm or somebody else can help me with this? My guess is that during the webpage/filesystem generation the actual filesize of my windows file is determined and used in the file header (with CR+LF for a EOL). But then the webpage is saved to the filesystem with only a LF for a EOL.

Can somebody confirm that and tell me what to do, to prevent that behaviour?

Thanks!