Description
I thought I would run this by you to get your opinion as I am at a loss to explain the change in behavior. I should point out that this is not a bug in your code but ultimately does affect your code.
In Arduino IDE 1.8.13 / M5Stack M5Core2 board the SD file "name" function returns a FQN name for any file in the root directory. Ex: "/Myfile.cfg". This is why I never noticed that SD.open requires a FQN when opening files in the root directory. I updated to IDE and board yesterday and noticed that the names returned after calling openNextFile() are no longer fully qualified. This change caused subsequent calls to SD.open() in your code to fail. It took me a long time to figure why SD.open was failing.
Were you aware of this change in behavior and if so any ideas where I might find documentation on the change?
I am also curious why a call to SD.open for a file in the root directly requires a FQN since this seems contrary to the documentation in sdfat which is what the SD Library is supposedly based on.
Sill using sdconfigfile and loving it !!!!!!
Update - Ive updated the orignal comments as It turns out this issue is part of the M5Stack Core2 ESP32 board library. Its not clear where M5Stacks SD library comes from since it has a version number (2.0.0) that is much higher then the latest released one (1.2.4) from Arduino. Ive emailed M5Stack them asking about the new behavior and will let you know once I hear back. I figure its better to know about it then not. Then again maybe everyone else already knows SD.open requires a FQN and Im behind the curve.