Not working when FS_NO_GLOBALS is defined

[DedeHai]

Hi

I just started using your library and in my sketch I am using the SD library as well as the SPIFFS library. This can be done by defining FS_NO_GLOBALS before including the #include <FS.h>
Now to access spiff files an fs:: has to be added before ever File and FS declaration when creating SPIFFS file objects.
I added the following code in ESPAsyncWebServer.h and replaced all instances of FS and File with the defines.

#if defined(FS_NO_GLOBALS)
#define SPFS fs::FS
#define SPFILE fs::File
#else
#define SPFS FS
#define SPFILE File
#endif

Now the files are served from the SPIFFs and I am still able to use the SD card for datalogging. The only disadvantage is that files cannot be served from the SD card by using the handler. I did not try this but there is probably a way to create another handler for SD files, just not sure how this would be done as I do not fully understand yet how your library actually works its magic.

Also I am not sure if the ESPAsyncWebServer.h is the right file to put the defines, maybe there is a better (more global) scope?
Would be great if you could add this functionality to your library so it is compatible with FS_NO_GLOBALS

[me-no-dev]

maybe it would work fine if I replace all FS/File instances with fs::FS/fs::File and not need a define

[DedeHai]

Maybe, I am not really familiar with name spaces in C. If you have a branch you want me to test this, let me know.

[probonopd]

I am affected by

hardware/esp8266/esp8266/cores/esp8266/FS.h:48:7: error:
previous definition of 'class fs::File'
class File : public Stream

[boblemaire]

I have the same issue (SPIFFS and SD) and solved it by doing the essentially the same thing but with:

using File = fs::File;
using FS = fs::FS;

upfront. BTW/ same changes seem to be necessary in WebResponseImpl.h and WebHandlerImpl.h.

Thanks for a really nice package.

[probonopd]

@boblemaire can you get https://gist.github.com/probonopd/aef8eb21d5c56dc96b7a1910ae58a4aa to compile? If so, how? If yes, this is a bug that should be fixed in the library? Thanks for your help.

[boblemaire]

probonopd,
Yes, I could compile it:

1. Added #define FS_NO_GLOBALS (before all of the includes)
2. Commented out your private.h which I assume contains your ssid and password. Added same in open code.
3. Used my versions of ESPAsyncWebServer with:

   using File = fs::File;
   using FS = fs::FS;

inserted at the start of

• class AsyncWebServerRequest (~line 122)
• class AsyncFileResponse in WebResponseImpl.h (~line 44)

I wouldn't go so far as to call it a bug as a lack of support for SD. ESPAsyncWebServer appears to have been written expressly for the ESP which has a native file system in the SPIFFs. So the file support is for the SPIFFs file system, which is simpler than the FAT file system on an SD card. Maybe it would have been better to call the File class something different like SPFile as was suggested in the lead post, but that's history. Sounds like me-no-dev is open to making an accommodation and I suspect something will be done. In a previous discussion that I came across the basic FS.h SD.h issue was resolved with the FS_NO_GLOBALS definition. Seems that ESPAsyncWebServer is just another instance of it.

All that said, this thing is fantastic. It is very well designed and coded (IMHO), and flexible enough to handle just about anything, including SD once you get compiled.

• class AsyncStaticWebHandler in WebHandlerImpl.h (~line 29)

[probonopd]

Thank you very much @boblemaire for your very helpful and detailed comment, you made me really happy as I am now unblocked in my further development of that sketch 👍

I agree that @me-no-dev's Async* libraries are a great plus and actually I wonder whether they could be made the default at some point. Each time I start an ESP project I tend to avoid external dependencies, but at some point it's always suggested to port the code to Async*.

[probonopd]

How would we get rid of the #define FS_NO_GLOBALS that is currently required at the top of the sketch?

[boblemaire]

I'm not comfortable having a conversation about this in the GitHub issues space. This developer is contributing some fine software, and I don't want to detract from his or her efforts with what amounts to a forum. I'm happy to have helped you get compiled. Good Luck.

[probonopd]

@boblemaire totally agree and I also don't want to detract @me-no-dev. Again, thanks for your help, highly appreciated. 👍