From 34c8fb66bd9204ebb278a2fb193eeabe10832f85 Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Thu, 20 Jul 2023 11:29:24 -0700 Subject: [PATCH] Remove the device and inode numbers from the API. (#81) * Remove the device and inode numbers from the API. As discussed [here], remove the fields which correspond to `st_dev`, `st_ino`, and `d_ino` in POSIX from the stat and directory entry structs. - Device numbers assume the existence of a global device number space, which creates implicit relationships between otherwise unrelated components. - Not all filesystem implementations have these numbers. And some that do have these numbers require extra implementation cost to retrieve them. - These numbers leak potentially sensitive or identifying information from the underlying filesystem implementation. In their place, provide some functions, `is-same-object`, `metadata-hash`, and `metadata-hash-at`, for explicitly testing whether two handles are the same file or have the same metadata, respectively. This doesn't cover all possible use cases for device and inode numbers, but we can add more functions as need arises. [here]: #65 (comment) * Remove the device and inode numbers from the API. As discussed [here], remove the fields which correspond to `st_dev`, `st_ino`, and `d_ino` in POSIX from the stat and directory entry structs. - Device numbers assume the existence of a global device number space, which creates implicit relationships between otherwise unrelated components. - Not all filesystem implementations have these numbers. And some that do have these numbers require extra implementation cost to retrieve them. - These numbers leak potentially sensitive or identifying information from the underlying filesystem implementation. In their place, provide some functions, `is-same-object`, `metadata-hash`, and `metadata-hash-at`, for explicitly testing whether two handles are the same file or have the same metadata, respectively. This doesn't cover all possible use cases for device and inode numbers, but we can add more functions as need arises. [here]: #65 (comment) * Explicitly document that the hash can contain a secret value. * Use a named `record` type instead of a `tuple` for hash values. --- example-world.md | 97 +++++++++++++++++++++++++++++++++++------------- wit/types.wit | 79 ++++++++++++++++++++++++++++----------- 2 files changed, 128 insertions(+), 48 deletions(-) diff --git a/example-world.md b/example-world.md index 9920763..b4d9d23 100644 --- a/example-world.md +++ b/example-world.md @@ -427,12 +427,23 @@ filesystem. filesystem. This does not apply to directories. +

record metadata-hash-value

+

A 128-bit hash value, split into parts because wasm doesn't have a +128-bit integer type.

+
Record Fields
+

type link-count

u64

Number of hard links to an inode. -

type inode

-

u64

-

Filesystem object serial number that is unique within its file system.

type filesize

u64

File size or length of a region within a file. @@ -596,11 +607,6 @@ merely for alignment with POSIX.

u32

A stream of directory entries.

This represents a stream of dir-entry.

-

type device

-

u64

-

Identifier for a device containing a file system. Can be used in -combination with `inode` to uniquely identify a file or directory in -the filesystem.

enum descriptor-type

The type of a filesystem object referenced by a descriptor.

Note: This was called filetype in earlier versions of WASI.

@@ -645,14 +651,6 @@ any of the other types specified.
Record Fields