extension("a.") now returns "." instead of "".
This matches both Python and Node.js standard library behavior as well
as my personal opinion on how this function should be defined.
Apologies for missing this in the code review.
* add more abosolutes
* added wrong files
* adding 2 tests and changing the function signatures because of lazy analysis not checking them
* fix a bug that got uncovered by lazy eval
* Add compile error when using WASI with openDirAbsolute and accessAbsolute
* typo
This intentionally diverges from the unix dirname command, as well as
Python and Node.js standard libraries, which all have this edge case
return the input path, unmodified. This is a footgun, and nobody should
have ever done it this way.
Even the man page contradicts the behavior. It says:
"strip last component from file name". Now consider, if you
remove the last item from an array of length 1, then you
have now an array of length 0. After you strip the last component, there
should be no components remaining. Clearly, returning the input parameter
unmodified in this case does not match the documented behavior. This is
my justification for taking a stand on this API design.
closes#6746closes#6727closes#6584closes#6592closes#6602
With this commit, the function tries to use more efficient syscalls, and
then falls back to non-positional reads.
The motivating use case for this change is to support something like the
following:
try io.getStdOut().writeFileAll(dest_file, .{});
* std.fs.File.copyRange and copyRangeAll return u64 instead of usize -
the returned value is how much of the `len` is transferred, so the
types should match. This removes the need for an `@intCast`.
* fix typo that removed a subtraction
* Fix the size of codegen.AnyMCValue which gave me a compile error when
I tried to build self-hosted for i386-linux.
* restore the coercion to u64 of syms_sect.sh_info. We want to make
sure the multiplication happens with 64 bits and not the smaller type
used by the ELF format.
* fix another offset parameter in link/Elf.zig to be u64 instead of usize
* add a nice little TODO note to help out Jakub
* FmtError already has FileTooBig in it; we just need to return it.
- Moves fs.rename functions to fs.renameAbsolute to match other functions outside of fs.Dir
- Adds fs.Dir.rename that takes two paths relative to the given Dir
- Adds fs.rename that takes two separate Dir's that the given paths are relative to (for renaming across directories without having to make the second path relative to a single directory)
- Fixes FileNotFound error return in std.os.windows.MoveFileExW
- Returns error.RenameAcrossMountPoints from renameatW
+ Matches the RenameAcrossMountPoints error return in renameatWasi/renameatZ
* Add a size_hint parameter to the read{toEnd,File}AllocOptions fns
* Rename readAllAlloc{,Options} to readToEndAlloc{,Options} as they
don't rewind the file before reading
* Fix missing rewind in test case
`std.os.getFdPath` is very platform-specific and can be used to query
the OS for a canonical path to a file handle. Currently supported hosts
are Linux, macOS and Windows.
`std.fs.Dir.realpath` (and null-terminated, plus WTF16 versions) are
similar to `std.os.realpath`, however, they resolve a path wrt to this
`Dir` instance.
If the input pathname argument turns out to be an absolute path, this
function reverts to calling `realpath` on that pathname completely
ignoring this `Dir`.
This way, we can remove more `kernel32` calls such as `RemoveDirectoryW`
or `DeleteFileW`, and use `std.os.windows.DeleteFile` instead which
is purely NT-based.
Replace them with `std.os.windows.OpenFile` instead. To allow
creation/opening of directories, `std.os.windows.OpenFileOptions`
now features a `.expect_dir: bool` member which is meant to emualate
POSIX's `O_DIRECTORY` flag.
