After going back and forth a few times I'm going to remove the stat syscall from v4 again. It can be added later but the design is not good yet and I don't want to commit to a bad API. Besides the libc is not ready to use it anyway.
In the meantime I want to document here what I intend to do with it so I don't forget. There are a bunch of things I want to return from a proper stat syscall:
- file type (regular file, directory, stream, device, symlink)
- file size (64-bit)
- permissions / execute bit
- modification date (64-bit seconds plus 32-bit nanoseconds to match time syscall)
Currently the execute bit can be set with chmod but there is no way to query it. We also need a modification date for build tools to work, for example Make and Samurai (Ninja in C). We may want to add an optional inode number as well, and maybe some other fields.
The syscall could be made extensible if it takes the size of the output struct as an argument and returns the size actually filled. This would allow later versions to add new fields to the struct without breaking older versions. This would complicate its implementation though; it might be better to just get it right from the start and not have to worry about sizes.
It should probably work like lstat, i.e. on a symlink it gives the details of the link, not the target. Separate syscalls should be used to read a link (into a 4096-byte buffer) and to create a link (this syscall was documented in v3 and earlier but was never used and is also removed in v4.) There is no support for symlinks in Onramp yet and there are some open questions on how it should work so symlinks will be excluded from at least the first minor version of v4.
Without stat, the libc will determine a file's type and size by opening it and calling other syscalls. If size succeeds it's a regular file; otherwise if dirent succeeds it's a directory; otherwise if readlink succeeds it's a symlink; otherwise it's a stream (or a device, but we can check if it's in /dev/ for that.) This has the downside that files must be opened to determine their properties, which may be restricted by permissions and may have side effects for devices. Even if stat is added later it will still be optional so this fallback to determine file properties will still be needed.
After going back and forth a few times I'm going to remove the stat syscall from v4 again. It can be added later but the design is not good yet and I don't want to commit to a bad API. Besides the libc is not ready to use it anyway.
In the meantime I want to document here what I intend to do with it so I don't forget. There are a bunch of things I want to return from a proper stat syscall:
Currently the execute bit can be set with chmod but there is no way to query it. We also need a modification date for build tools to work, for example Make and Samurai (Ninja in C). We may want to add an optional inode number as well, and maybe some other fields.
The syscall could be made extensible if it takes the size of the output struct as an argument and returns the size actually filled. This would allow later versions to add new fields to the struct without breaking older versions. This would complicate its implementation though; it might be better to just get it right from the start and not have to worry about sizes.
It should probably work like lstat, i.e. on a symlink it gives the details of the link, not the target. Separate syscalls should be used to read a link (into a 4096-byte buffer) and to create a link (this syscall was documented in v3 and earlier but was never used and is also removed in v4.) There is no support for symlinks in Onramp yet and there are some open questions on how it should work so symlinks will be excluded from at least the first minor version of v4.
Without stat, the libc will determine a file's type and size by opening it and calling other syscalls. If size succeeds it's a regular file; otherwise if dirent succeeds it's a directory; otherwise if readlink succeeds it's a symlink; otherwise it's a stream (or a device, but we can check if it's in
/dev/for that.) This has the downside that files must be opened to determine their properties, which may be restricted by permissions and may have side effects for devices. Even if stat is added later it will still be optional so this fallback to determine file properties will still be needed.