busybox-w32, branch symlink

libbb: fix detection of relative paths in xreadlink.c

2021-03-01T09:37:50+00:00

In xmalloc_follow_symlinks() the code to detect relative paths needs to be altered for WIN32. We don't want C:/path to be treated as a relative path.

Allow `rename()` to work across drives

2021-03-01T09:35:55+00:00

Signed-off-by: Johannes Schindelin

Do not use `rename()` for symlinks

2021-03-01T09:35:31+00:00

That function would rename the _target_, not the link. Signed-off-by: Johannes Schindelin

Fix `xmalloc_readlink()` again

2021-03-01T09:31:21+00:00

In e86a3ddd8 (win32: make readlink(2) implementation unconditional, 2021-02-12), we removed the special casing of `errno == ENOSYS` when trying to follow symlinks. However, that handling really was necessary: - When we followed a symlink, and found a non-symlink, and then called `readlink()` with that non-symlink, we got `errno == ENOSYS` on Windows (translated from `ERROR_NOT_A_REPARSE_POINT`), and we did want to stop the loop and return the current path in that case. (Noted by Johannes Schindelin.) - When readlink() called DeviceIoControl() for files on certain filesystems (e.g. FAT or a CDROM) it returned `errno == ENOSYS` (translated from ERROR_INVALID_FUNCTION). Revert the part of the patch which handled `ENOSYS` on Windows.

win32: let `resolve_symlinks()` _really_ resolve symbolic links

2021-03-01T09:30:29+00:00

When one tries to call `CreateFile()` with a reparse point, it will trigger an `ERROR_INVALID_NAME` unless `FILE_FLAG_OPEN_REPARSE_POINT` is passed. However, _when_ that flag is passed, it does not open a handle to the symlink _target_, but to the symlink itself. Signed-off-by: Johannes Schindelin

readlink(): do `NUL`-terminate the result

2021-03-01T09:24:34+00:00

Otherwise we're provoking buffer overruns. Signed-off-by: Johannes Schindelin

win32(symlink): fix logic to determine the type of the symlink

2021-03-01T09:23:43+00:00

On Windows, there are file symlinks and directory symlinks. When trying to `opendir()` a symlink marked as `file`, it will fail. Even if the target is a directory. Because it's the wrong symlink type. To address this, our `symlink()` function calls `stat(target, ...)` to see whether the target exists and is a directory. The problem is that this `target` can be a relative path, and the link path can _also_ be a relative path. Example: `symlink("dir", "uh/oh")`. In this example, the target might say `dir`, but it is relative to `uh/oh`, i.e. we need to `stat("uh/dir", ...)`. This is necessary to pass the `cp` tests because they first create such a directory symlink and then try to copy it while dereferencing symlinks, i.e. calling `opendir()` on the symlink. Signed-off-by: Johannes Schindelin

win32: move is_absolute_path()

2021-03-01T09:20:58+00:00

Make is_absolute_path() a function rather than a macro and move it from ash.c into mingw.c.

win32: workaround for lazy loading issue on Windows 7

2021-03-01T09:07:58+00:00

Investigating why free(1) wasn't working on Windows 7 I found it's possible for LoadLibraryEx to fail with exactly the flags we're using. Work around this. This probably also explains GitHub issue #204.

which: changes to standalone shell support

2021-02-25T08:39:02+00:00

- If 'which' is run from an executable called 'which.exe' it suggests we aren't in a standalone-shell-mode shell. Don't run any standalone-shell-specific code. - Use case-insensitive comparisons when testing the names of executables. - When the argument is 'busybox' any executable name starting with 'busybox' should match. - Since 'busybox' is now treated as an applet in standalone shell mode there's no need to test for this explicitly.