Description

In the filesystem example, ls / give an -ENOENT error; the same happens in #14397 (coap file server) when exploring the file system root.

The filesystem example has nothing mounted there, so it's kind of OK, but confusing and begging for workarounds. (Eg. in the file server, I briefly considered adding a handler for listing all mount points, but it'd depend on the application whether that should be used on / or not).

A tricky point about using such workarounds is that listing mount points has stricter thread safety requirements than listing a directory (there mustn't be any (un)mounts during that).

Comparison to Linux systems

On a Linux system (probably all of POSIX or UNIX), there's always a root mount point. Mounting happens at mount that is already a directory (and thus visible from the top-level file system).

On RIOT, there's not necessarily a root-mounted file system, and if there is, AFAICT there's no necessity for a mount inside a different file system to have a corresponding directory in the underlying one.

Possible solutions

• Suggest the Linux-style mounting pattern without enforcing it. Adjust the vfs example to use this, either by mounting the constfs at /, adding an empty /sda and putting its remaining data into an in-filesystem /const or a second constfs mount there
• Enforce the pattern. That'd be rather troublesome, eg. it'd need to prevent rmdir if something is mounted in there.
• Allow directory listing even on an empty root. That might lead to different unexpected results, for a) it might be producing entry names containing slashes, and b) it'd combine oddly with nested mounts (as they'd either not list their sub-mounts unlike the empty root mount, or they'd need changes in a lot of places to also look for mount points).

I'm leaning towards the first, but am rather new to the file system. Would that be in line with general VFS ideas?