File systems report names with leading slashes

[chrysn]

Description

Several file systems (at least constfs and littlefs) return file names with leading slashes.

Steps to reproduce the issue

In the filesystems example with the default littlefs backend for sda:

> ls /const
/hello-world
/hello-riot
total 2 files
> format
> mount
> tee /sda/foo hello
> ls /sda
/.
/..
/foo
total 3 files

In contrast, fatfs (with an externally created image) gives slash-free names:

> ls /sda
FOO
EMPTY
FOLDER
GARBAGE
total 4 files

Expected results

The vfs_dirent_t struct describes a field for "file name, relative to its containing directory".

That indicates that it can only be a file name, ie. a string that contains any characters except '\0' and '/'. It may also help to have some explicit statement in here.

Context

This was found in #14397, which (working as a file server with URIs) has stricter requirements on the precision of names.

As this affects at least two file systems, this should be tracked in separate bugs for:

• littlefs (closed in pkg/littlefs*: align readdir() with documentation #17623 )
• constfs (closed in fs/constfs: omit leading '/' in readdir()  #17626)

I can create and look into those in particular, but a statement from someone more familiar with the design of the file systems calls would be useful (thus the "help" tag, feel free to remove that with a clarifying remark).

Versions

current RIOT master (6ef4276) on native

[benpicco]

IIRC spiffs also starts with a leading /, so fatfs would be the odd one here.
Can you open files with and without the leading slashes?

[chrysn]

Testing with constfs:

> ls /const
/hello-world
/hello-riot
total 2 files
> cat /const/hello-world
Hello World!
> cat /const//hello-world
file /const//hello-world does not exist

I can open the files as they should be assembled in full paths; thing is, the leading slash inside the file name that is shown in ls can't even be expressed in a path. (In a URI it'd make a /const/%2Fhello-world, POSIX-ish paths have no such escapes).

My impression of how this came about is that a) file systems expect to be mounted at /, and b) may be disposed to list all files nested in a directory.

[chrysn]

Thanks @benpicco for addressing this in both affected file systems; closing. (If this comes back in any other file system, that can be addressed in a separate issue; for now the popular ones set the style and are consistent).