No problem
In addition FS.h makes no sense at all, too.
You can ONLY use in a sketch, and ONLY if you don't need extended features of the underlying FS.
You just can't use it in a library, because it misses the most basic functions.
- it neither allows to block accesses to the underlying FS (in interrupts) or interfaces, nor does it do that itself - try to use SPI and a file on SPI (in interrupts)! You don't even know that the file is on SPI... FS does not know it.
- it does not even give any information about the underlying FS, so a library can't do this, too
- You can't use it to store files as fast as possible - no preallocate/truncate
- Not to speak of other useful functions.
It's more a thereotical thing - it exists - fine - but i think nobody ever used it ouside from short examples. There is just no real practical use, at the moment. Outside from most simple sketches.
So, it's not possible to use it. It's not posible to write i.e. a waveplayer or other useful things. SD works - yes.. because it handles these things. Now, try to record.
hehe, try to record to a SD on SPI and attach a SPI display .. without even knowing that your read() edit: ehh. sorry, write()
uses SPI. It does not even know that it accesses SD.
No, if you want to get something useful working, you need to inlcude all existing filesystems and just ignore FS.h. That's how it is.
And even with that - you can block SPI only and only one SPI interface. No way to do that with SDIO. Or others, like QSPI.
Would be more easy with proven software like RTOSes. They provide ways.