Skip to content

Problem with SPIFFS and FS exists. #1264

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rrowe629 opened this issue Mar 26, 2018 · 9 comments
Closed

Problem with SPIFFS and FS exists. #1264

rrowe629 opened this issue Mar 26, 2018 · 9 comments
Labels
Status: Stale Issue is stale stage (outdated/stuck)

Comments

@rrowe629
Copy link

rrowe629 commented Mar 26, 2018

Hardware:

Board: ADAFRUIT ESP32 Feather
Core Installation/update date: 26/mar/2018
IDE name: Arduino IDE
Flash Frequency: 80Mhz
Upload Speed: 115200

Description:

I've been chasing a problem with ESPAsyncWebServer and serving gzipped files. I've narrowed it down to the fact that line 501 of WebResponses.cpp is never true. Here's the line:

 if(!download && !fs.exists(_path) && fs.exists(_path+".gz")){

A bit more research leads me to believe that there is a problem passing SPIFFS to the function. I constructed a sketch to test this theory, which is included below. Sure enough, when passing SPIFFS to the testSPIFFS function, I get a different result. I set Core Debug Level to "Debug", but no debug messages are displayed. I've uploaded a file called "index.html" to SPIFFS, but there is no "index.html.gz" present. Here's the output I get from my sketch:

SPIFFS.exists("/index.html") : 1
SPIFFS.exists("/index.html.gz") : 0
fs.exists("/index.html") : 1
fs.exists("/index.html.gz") : 1

SPIFFS returns the correct result, FS has a false positive on index.html.gz. This is the same behavior I am seeing in WebResponses.cpp - exists always returns true whether the file is there or not.

Sketch:

#include "SPIFFS.h"

void testSPIFFS(FS &fs, String path) {
String pathWithGz = path + ".gz";
Serial.printf("fs.exists("%s") : %d\n", path.c_str(), fs.exists(path));
Serial.printf("fs.exists("%s") : %d\n", pathWithGz.c_str(), fs.exists(pathWithGz));
}

void setup() {
Serial.begin(115200);
SPIFFS.begin();
String path = "/index.html";
String pathWithGz = path + ".gz";

Serial.printf("SPIFFS.exists("%s") : %d\n", path.c_str(), SPIFFS.exists(path));
Serial.printf("SPIFFS.exists("%s") : %d\n", pathWithGz.c_str(), SPIFFS.exists(pathWithGz));
testSPIFFS(SPIFFS, path);
}

void loop() {

}


### Debug Messages:

No additional Debug Messages.

@me21
Copy link

me21 commented Aug 7, 2018

I confirm, I've hit the issue myself, only with built-in web server.
fs.exists("/") returns true, SPIFFS.exists("/") returns false inside the constructor of StaticRequestHandler class.

@alanswx
Copy link

alanswx commented Nov 4, 2018

This just caused me a lot of trouble. I saw your post and temporarily modified ESPAsyncWebServer:

bool Fileexists(FS &fs,const char* path)
{
File f = fs.open(path, "r");
return (f == true) && !f.isDirectory();
}

bool Fileexists(FS &fs,const String& path)
{
return Fileexists(fs,path.c_str());
}

AsyncFileResponse::AsyncFileResponse(FS &fs, const String& path, const String& contentType, bool download, AwsTemplateProcessor callback): AsyncAbstractResponse(callback){
_code = 200;
_path = path;

//if(!download && !fs.exists(_path) && fs.exists(_path+".gz")){
if(!download && !Fileexists(fs,_path) && Fileexists(fs,_path+".gz")){

And it seemed to fix the problem. Is this a subclass problem? Where is the right place to fix it? I wonder if this code just broke the other file systems, like SD Cards.

@judge2005
Copy link
Contributor

I just hit this too. Is there a fix for this anywhere?

@judge2005
Copy link
Contributor

Submitted this issue to esp-idf: espressif/esp-idf#3427

@stale
Copy link

stale bot commented Jul 31, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: Stale Issue is stale stage (outdated/stuck) label Jul 31, 2019
@me21
Copy link

me21 commented Aug 1, 2019

It can be safely closed, fixed by pull request #2763

@stale
Copy link

stale bot commented Aug 1, 2019

This stale issue has been automatically closed. Thank you for your contributions.

@stale stale bot removed the Status: Stale Issue is stale stage (outdated/stuck) label Aug 1, 2019
@stale
Copy link

stale bot commented Sep 30, 2019

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: Stale Issue is stale stage (outdated/stuck) label Sep 30, 2019
@stale
Copy link

stale bot commented Oct 14, 2019

[STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions.

@stale stale bot closed this as completed Oct 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Stale Issue is stale stage (outdated/stuck)
Projects
None yet
Development

No branches or pull requests

4 participants