In the gcc implementation (and devkitARM as well), it calls stdio.h's remove, which resolves to https://github.com/devkitPro/newlib/blo ... o/remove.c which then calls _unlink_r, aka https://github.com/devkitPro/newlib/blo ... e/unlink.c and ends up in libctru, right here: https://github.com/devkitPro/libctru/bl ... dev.c#L886.
This leaves std::filesystem::remove all but crippled, as it can only remove files, and not folders/directories at all.
I believe the way to go fixing this is make newlib/libgloss have a remove replacement that follows POSIX remove (instead of ANSI C remove that only knows about files): https://pubs.opengroup.org/onlinepubs/9 ... emove.html, specifically this part:
Sorry for the wall of text, I noticed the problem a long time ago and only now discovered the why of it, after some digging on github, so I wrote everything as it came to me.If path does not name a directory, remove(path) shall be equivalent to unlink(path).
If path names a directory, remove(path) shall be equivalent to rmdir(path)
Thanks for the libraries and toolchains, I'd love to see this fixed and being able to use std::filesystem to its fullest, have a nice day!