Kinda funny, kinda sad....

[synman]

there are umpteen hundred forks and derivatives of this code yet the only one that truly works is the original!

I know, not an issue here, but I had to share after a day and a half of dorking around to come back to the original and it be more stable / reliable / functional then all the others.

Thanks for your work!

[synman]

Here's my clone with the latest version of sdFat working for the most part (timestamps are screwed up at the moment), a couple other features added (basic eeprom, mDNS, espota) and a platformio.ini file in place. It was sure tough going back to the Arduino IDE.

https://github.com/synman/ESPWebDav/tree/sdFat-2.2.0

[cristianoag]

It looks like major issue with sdFat-2.2.0 is the lack of flexibility in scenarios of Shared SDI like the one required by those solutions. They have the "printer" and the ESP8266 disputing the bus. It is amazing the attempt the use CS to control concurrent access, but some printers don't allow the sd initialization with sdFAT-2.2.0. At this moment I don't know exactly why. yet!

[synman]

here's another branch I did where I dropped the external sdFat dependency entirely.

I also dropped webdav too.... got it running in platformio and. few other major departures. I went well off the path with this fork. Same underlying bus sharing issues exist though but it works well enough for me to sneak in updated bin files (firmware updates) and doesn't interfere with my printer using the bin files to flash new firmwares on boot.

https://github.com/synman/ESPWebSvr/tree/no-sdfat

[cristianoag]

Yeah. Saw that one. Great job indeed. A few additional info on the bus issues. If you power the board with the printer off and inserted on the card slot, it enabled the webdav. The sd.begin works well. Then if you turn on the printer, the code detects correctly that the printer is using the card, then after some time it releases it back. but then the folder comes empty. I noticed that on the code below, baseFile.open comes ok, but childFile.openNext(&baseFile, O_READ) is always false. If you turn off the printer, childFile.openNext(&baseFile, O_READ) is true again. sd.begin never completes ok with the printer on.

SdFile baseFile;
baseFile.open(uri.c_str(), O_READ);
sendPropResponse(false, &baseFile);

if((resource == RESOURCE_DIR) && (depth == DEPTH_CHILD))	{
	// append children information to message
	SdFile childFile;
	while(childFile.openNext(&baseFile, O_READ)) {

[cristianoag]

of course. original firmware from FYSETC also doesn't work. but this one https://github.com/bigtreetech/BTT-SD-TF-Cloud-V1.0 with the respective board works flawlessly. however, they copied the open source idea but "of course" only shared the binary and not the source code!

[synman]

I have that BTT card too but haven't messed with it. You should see how macOS responds to the fysetc card. macOS gets mad very quickly.

[cristianoag]

Figured out. It is a hardware difference between the FYSETC board and BTT. BTT has different resistors and is handling better the signals coming from the printer. I installed your code into the BTT and it is working ok on the printer.

[ardyesp]

Thanks for your comments Its good to know the code still works after so many years.