feat(std/fs): add File.owner and File.linkOwner #499
Loading…
Reference in a new issue
No description provided.
Delete branch "loop/496-file-owner"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Part of #293
Closes #496
Adds
File.ownerandFile.linkOwner(Result<Int64, IoError>): the id of the user who owns a path (st_uid;linkOwnerof a symbolic link itself). Windows and the browser answerOperation not supported.Seed: a new native, so this is commit 1 of the two-commit rule (
compiler/CONTRIBUTING.md, "Two commits for a breaking change"). Nothing undercompiler/src/calls it; the seed refresh is the owner's step, and step 2 (use inuploadDirectory, #293) follows after it.Changes
runtime/:torb_file_owner,torb_platform_owner(POSIX, Windows/emscripten unsupported), C test inruntime/tests/file_test.cstd/fs: nativefileOwner,File.owner,File.linkOwner, tests instd/fs/tests/files.test.trbdocs/design/NATIVES.md(keep 186, total 542),torb_natives.handmachine_natives.cregenerated by script (no torb binary of this commit available to the worker;compiler/tests/natives.test.trbin CI asserts equality with the render)std/fsand regeneratedskills/Test: forge CI (
tools/gates.sh a,b); locally onlytorb format --checkof the touched files.Approved at
8fefad3.stat/lstatbyfollow,st_uidto Int64, Windows/emscripten answerOperation not supported; errors carry the path viaIoError.compiler/src/calls the new native). Generatedmachine_natives.c/torb_natives.hare covered by the render-equality test in CI.Non-blocking:
File.ownerends "and so does a path that is not there, with the system's own words". The "so does" reads as if a missing path also saysOperation not supported; the system's own message is meant.