This reverts commit 0c99ba1eab63865592bb084feb271cd4e4b0357e, reversing
changes made to 5f92b070bf284f1493b1b5d433dd3adde2f46727.
This caused a CI failure when it landed in master branch due to a
128-bit `@byteSwap` in std.mem.
* fs/test.zig: use arena allocator more consistently
* fs/test.zig: remove unnecessary type information
Zig can (now?) implicitly cast a `&.{ "foo"}` when passed to
`fs.path.join()`, so the `[_][]const u8` is unnecessary.
* fs/test.zig: Use fs.path.join() for longer paths
Replace long path constructions (that use several "++ path_sep ++")
with a single call to `fs.path.join`. Seems more readable to me.
* fs/test.zig: fmt
`statFile` now only uses `os.fstatatWasi` when not linking libc, matching the pattern used throughout other `Dir` functions. This fixes the compilation error: `error: struct 'c.wasi.Stat' has no member named 'fromFilestat'` (which the added test would have failed with)
In theory, localhost could be mapped to a different address via the LMHOSTS file, so using 127.0.0.1 should remove that potential wrinkle and allow the drive-absolute -> UNC transformation to work on any(?) setup.
Also print the error name to ensure it gets printed in CI (aarch64-windows ReleaseSmall seemed not to print the error in the last intermittent UNC failure)
These two tests can't be disambiguated at comptime, since the filesystem that the test is running on also matters for whether or not POSIX_SEMANTICS / IGNORE_READONLY_ATTRIBUTE can actually be used (since they are only supported on NTFS).
On Windows, a directory that's set as the current working directory is
not allowed to be removed. This can cause error on `deleteTree` if the
CWD is set to the file to be removed and will cause `error.FileBusy`.
However, due to `tmp.cleanup()` ignoring the errors, the folder removal error will
be ignored. The only test violating this is `windows_spawn`. As a
solution, setting the parent directory to be the CWD before deletion
will allow the cleanup to pass.
Deleting a read-only file should result in `AccessDenied` (`CANNOT_DELETE`).
Note: This test was observed to fail when the file is closed then reopened
before the change in permission due to the absence of
`FILE_WRITE_ATTRIBUTES` when re-opened. (see #15316).
This reverts commit 772a0eb68ac95b7e24508580499b49872fdb541f, reversing
changes made to 0bb178bbb2451238a326c6e916ecf38fbc34cab1.
This needs a rebase against master branch - it has build-breaking merge
conflicts. I also added a "changes requested" review on the original
pull request.
This branch largely reverts 58f961f4cb9875bbce3070969438ecf08f392c9f. I
would like to revisit the proposal to modify the standard library in
this way and think more carefully about it before adding isAbsolute()
checks everywhere.
This is a breaking change to the API. Instead of the first path
implicitly being the current working directory, it now asserts that the
number of paths passed is greater than zero.
Importantly, it never calls getcwd(); instead, it can possibly return
".", or a series of "../". This changes the error set to only be
`error{OutOfMemory}`.
closes#13613
Make the test use the minimum length and set MAX_NAME_BYTES to the maximum so that:
- the test will work on any host platform
- *and* the MAX_NAME_BYTES will be able to hold the max file name component on any host platform
Each u16 within a file name component can be encoded as up to 3 UTF-8 bytes, so we need to use MAX_NAME_BYTES to account for all possible UTF-8 encoded names.
Fixes#8268
Before this commit, the modified test would fail with `FileNotFound` because the `entry.dir` would be for the entry itself rather than the containing dir of the entry. That is, if you were walking a tree of `a/b`, then (previously) the entry for `b` would incorrectly have an `entry.dir` for `b` rather than `a`.
`getdents` on Linux can return `ENOENT` if the directory referred to by the fd is deleted during iteration. Returning null when this happens makes sense because:
- `ENOENT` is specific to the Linux implementation of `getdents`
- On other platforms like FreeBSD, `getdents` returns `0` in this scenario, which is functionally equivalent to the `.NOENT => return null` handling on Linux
- In all the usage sites of `Iterator.next` throughout the standard library, translating `ENOENT` returned from `next` as null was the best way to handle it, so the use-case for handling the exact `ENOENT` scenario specifically may not exist to a relevant extent
Previously, ENOENT being returned would trigger `os.unexpectedErrno`.
Closes#12211
