Inconsistent use of "root" or "/spiffs/" in file module across esp8266 and esp32 targets?

[jim80]

So I first noticed this in testing some other code, using /examples/...../httpserverputfile/ to upload a few files for testing on ESP8266 - that worked fine. I then plugged in an esp32 and built for that, and it gives "file Not found" exceptions.
So, I modified it to prepend "/spiffs" to the filepath before opening the file, and yes, it worked fine.
Back to the esp8266, and I upload and test my modified example, which works, but leads to files named "/spiffs/test.jpg", for example.
So, point one - the example doesn't work as is for esp32 ("on my computer").
Point 2 - I'm now a little confused! I know that I should really use the config.file.root from the file manifest, but it's actually the same for both build targets :

"esp": { "modules": { "*": "$(MODULES)/files/file/esp/*" }, "config": { "file": { "root": "/spiffs/" } } }, "esp32": { "modules": { "*": "$(MODULES)/files/file/esp32/*" }, "config": { "file": { "root": "/spiffs/" } } },

Any clarification would be much welcomed, many thanks!

[bfriedkin]

@jim80 -

I tested the httpserverputfile app unmodified on both my Moddable One ESP8266 and Moddable Two ESP32 products. The application worked as expected on both devices.

For testing I used this cURL command line:

curl --data-binary "@/users/brianfriedkin/test.txt" http://192.168.1.42/spiffs/test.txt -v

SPIFFS is supported for both ESP32 and ESP8266, though they are different implementations. On ESP32, you are required to prepend the file root /spiffs/ to the path name. On ESP8266 this is not required.

The SPIFFS file system is flat. There are no directories. So if you write a file on ESP8266 named /spiffs/test.jpg the file will be named /spiffs/test.jpg. The slashes are simply characters in the file name.

We specify the /spiffs/ root on both targets mostly for consistency, since both targets support SPIFFS.

I hope this helps to clarify your understanding.

Regards,
Brian

[jim80]

Yes, it does, many thanks Brian!
Off the top of my head since I'm away from my build machine right now, the example code would trace (in your example) the remote file path as curl --data-binary "@/users/brianfriedkin/test.txt" http://192.168.1.42/test.txt -v, in other words omitting the /spiffs/ part of that path ? ?
https://github.com/Moddable-OpenSource/moddable/blob/public/examples/network/http/httpserverputfile/main.js
trace(curl --data-binary "@/users/[your directory path here]/test.txt" http://${Net.get("IP")}/test.txt -v\n);
That's the initial thing I identified ....
So, you are saying don't differentiate between esp8266 / esp 32, always use /spiffs prepended to the file path, and just accept the anomaly and the loss of 7 chars from the maximum spiffs filename length?
Surely I would then have to differentiate the 32/8266 "environment" to read a file, prepending /spiffs as appropriate? In which case why not do it the first place?
Sorry to question you further on this!
Many thanks for your input, sorry to be a PITA

[bfriedkin]

@jim80 -

No worries... When running the example using the cURL command line I previously used, the application traces the following to the console:

curl --data-binary "@/users/[your directory path here]/test.txt"  http://192.168.1.35/test.txt -v

The example app doesn't try to address platform specific rules regarding file system roots. The app demonstrates the basics on how to implement an HTTP server that accepts the request body in fragments and save those fragments to a file. You had written that the app didn't work for you on ESP32. The cURL command line I provided shows how to make the app work on both ESP8266 and ESP32 by modifying the cURL HTTP URI path.

Tracing out the value parameter delivered to the callback in the Server.status message shows the path:

case Server.status:     // request status received
     let path = value;          // file path is HTTP path
     trace(`${path}\n`);

In my version the path traced is /spiffs/test.txt.

The technique I used leverages the fact that ESP32 requires files to use the /spiffs file root. It allows the example to run on both device targets without any code changes. You could certainly modify the logic that constructs the file name to better suit your needs.

Regards,
Brian