busybox-w32/libbb/xreadlink.c, branch cron_changes

win32: replace readlink(2)

2023-08-21T11:46:52+00:00

The Windows implementation of readlink(2) has caused problems in the past. As, for example, with commit c29dc205d2 (win32: fix implementation of readlink(2)). Most uses of readlink(2) in BusyBox are actually calls to the (considerably more convenient) library function xmalloc_readlink(). Implement a Windows version of that and used it instead of readlink(2). This improves the handling of symbolic links (and similar reparse points) in CJK and UTF-8 code pages. Saves 48-80 bytes.

realpath: improved support for Windows paths

2021-10-13T15:44:45+00:00

Upstream commit 94eb1c4dc (libbb: better coreutils compatibility for realpath) made some changes to xmalloc_realpath_coreutils(). This now needs to be updated to handle Windows paths. - Expose the macro is_unc_path() and part of the recent change to bb_get_last_path_component_nostrip() as a separate funtion, get_last_slash(); - Convert a couple of errors relating to network filesystems to ENOENT; - Adjust xmalloc_realpath_coreutils() to handle Windows directory separators, relative paths and UNC paths.

Merge branch 'busybox' into merge

2021-10-13T13:37:51+00:00

win32: rename is_absolute_path()

2021-10-12T12:43:15+00:00

As the comment pointed out is_absolute_path() was misnamed. Rename it to is_relative_path() and change the sense of all tests.

libbb: better coreutils compatibility for realpath

2021-10-08T23:47:12+00:00

Add some tests which coreutils realpath pass but BusyBox realpath fails (bar one). Adjust xmalloc_realpath_coreutils() so the tests pass: - Expand symbolic links before testing whether the last path component exists. - When the link target is a relative path canonicalize it by passing it through xmalloc_realpath_coreutils() as already happens for absolute paths. - Ignore trailing slashes when finding the last path component and correctly handle the case where the only slash is at the start of the path. This requires ignoring superfluous leading slashes. - Undo all changes to the path so error messages from the caller show the original filename. function old new delta xmalloc_realpath_coreutils 214 313 +99 Signed-off-by: Ron Yorston Signed-off-by: Denys Vlasenko

win32: better handling of nested symlinks

2021-08-12T10:49:56+00:00

Our realpath(3) implementation uses xmalloc_follow_symlinks() to expand symlinks. This detects when symlinks are too deeply nested but didn't set errno, so anything calling realpath(3) was unable to say what had gone wrong. (For example, 'ls -L' or 'stat -L'.) Set errno to ELOOP. This then leads to the problem that Windows doesn't know about ELOOP so reports 'Unknown error'. Add a replacement for strerror(3) which returns a sensible message. Costs 96 bytes.

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.

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: make readlink(2) implementation unconditional

2021-02-12T14:02:28+00:00

There doesn't seem to be much advantage in having readlink(2) as a configuration option. Making it unconditional reduces divergence from upstream and allows the removal of a check for ENOSYS that's been in busybox-w32 since the start.

Merge branch 'busybox' into merge

2019-08-16T08:45:21+00:00