`fs` module's design decision

language design
1

  • Shouldn't it be either

    1. there also exist create_file and read_file just like create_dir and read_dir, or
    2. there exist Dir struct and you use it via Dir::create and Dir::open.

  • Shouldn't it be either

    1. Permissions is independently created from File and set to it by set_permissions, or
    2. Permissions is only returned by Metadata::permissons as a &mut and set_readonly is all you have to do (you don't have to do set_permissions after that).

  • Why FileType is a struct with mutually exclusive is_* methods instead of being an enum with same variants:

    enum FileType {
  Dir,
  File,
  Symlink
}
1 Like
2

The short version is that files are complicated, and a filepath could exist but be not a directory, file, or symlink.

There's IIRC active (but intermittent) work in this area to add a type for an "open" filehandle to a directory. It doesn't exist currently because this wasn't a semantic that std was confident saying was both

  • reasonably portable between OSes, and
  • generally a desirable operation.

The filesystem is inherently a shared, aliased resource (e.g. with other processes on a multitasking OS). As such, using "pseudo atomic" modifications is a better model of the actual behavior, and helps manage TOCTOU style issues.

11 Likes
3

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.