`fs` module's design decision

[rin]

• 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
  }
  

[CAD97]

@rin

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

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

@rin

[Shouldn't] there exist Dir struct and you use it via Dir::create and Dir::open.

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.

@rin

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).

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.