Unnamed repository; edit this file 'description' to name the repository. http://euandre.org/git/grovel/atom?h=main 2024-01-05T08:47:09Z 2024-01-05T08:47:09Z EuAndreh eu@euandre.org 2024-01-04T23:36:02Z urn:sha1:8492f115890d56c98c1da24b9fdf26bb1b714c05 2023-11-06T18:44:53Z Alexey Izbyshev izbyshev@ispras.ru 2023-10-07T18:02:18Z urn:sha1:2265a4c9b0825306794eeb0812c783692313d972 AT_NO_AUTOMOUNT is implied for stat/lstat/fstatat syscalls since Linux 3.1 (commit b6c8069d3577481390b3f24a8434ad72a3235594). However, this is not the case for statx syscall, which defaults to automounting, so this flag must be passed explicitly when statx is used to implement stat-like functions. This change affects only arches which use 32-bit seconds in struct kstat, as well as out-of-tree/future ports to arches which lack SYS_fstatat. 2023-08-19T18:46:20Z наб nabijaczleweli@nabijaczleweli.xyz 2023-08-17T20:05:14Z urn:sha1:7291c6c66a8d033bb487e6d8c8b003c8a7b6a550 This is the only missing part in struct statvfs. The LSB calls [f]statfs() deprecated, and its weird types are definitely off-putting. However, its use is required to get f_type. Instead, allocate one of the six spares to f_type, copied directly from struct statfs. This then becomes a small extension to the standard interface on Linux, instead of two different interfaces, one of which is quite odd due to being an ABI type, and there no longer is any reason to use statfs(). The underlying kernel type is a mess, but all architectures agree on u32 (or more) for the ABI, and all filesystem magicks are 32-bit integers. Since commit 6567db65f495cf7c11f5c1e60a3e54543d5a69bc (prior to 1.0.0), the spare slots have been zero-filled, so on all versions that may be reasonably be encountered in the wild, applications can rely on a nonzero f_type as indication that the new field has been filled in. 2022-10-19T18:01:31Z Rich Felker dalias@aerifal.cx 2022-09-26T21:14:18Z urn:sha1:246f1c811448f37a44b41cd8df8d0ef9736d95f4 originally the namespace-infringing "large file support" interfaces were included as part of glibc-ABI-compat, with the intent that they not be used for linking, since our off_t is and always has been unconditionally 64-bit and since we usually do not aim to support nonstandard interfaces when there is an equivalent standard interface. unfortunately, having the symbols present and available for linking caused configure scripts to detect them and attempt to use them without declarations, producing all the expected ill effects that entails. as a result, commit 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c was made to prevent this, using macros to redirect the LFS64 names to the standard names, conditional on _GNU_SOURCE or _LARGEFILE64_SOURCE. however, this has turned out to be a source of further problems, especially since g++ defines _GNU_SOURCE by default. in particular, the presence of these names as macros breaks a lot of valid code. this commit removes all the LFS64 symbols and replaces them with a mechanism in the dynamic linker symbol lookup failure path to retry with the spurious "64" removed from the symbol name. in the future, if/when the rest of glibc-ABI-compat is moved out of libc, this can be removed. 2022-05-04T14:51:00Z Rich Felker dalias@aerifal.cx 2022-05-04T14:51:00Z urn:sha1:05a55868ff0f42cfc8701c7977322aa4c8e1aca3 this avoids the need for implementation-internal callers to depend on the nonstandard AT_EMPTY_PATH extension to use __fstatat and isolates knowledge of that extension to the implementation of __fstat. 2022-05-02T03:25:21Z Rich Felker dalias@aerifal.cx 2022-04-28T06:24:44Z urn:sha1:fb10dc288d74442ea85c26b0ac3810f05377cba9 riscv32 and future architectures only provide statx. 2022-05-02T03:25:21Z Rich Felker dalias@aerifal.cx 2022-04-28T06:14:34Z urn:sha1:c9ba0769a749e4e08fd8a8815b8ced96fba4927b this makes it so we can drop direct stat syscall use in interfaces that can't use the POSIX namespace. 2022-05-02T03:25:21Z Rich Felker dalias@aerifal.cx 2022-04-28T06:02:38Z urn:sha1:7edbcbeb76cb46381c34e2c0491dcc459cd5fa46 instead, use the fstatat/stat functions, so that the logic for which syscalls are present and usable is all in fstatat. this results in a slight increase in cost for old kernels on 32-bit archs: now statx will be attempted first rather than just using the legacy time32 syscalls, despite us not caring about timestamps. however, it's not even clear that the legacy syscalls *should* succeed if the timestamps are out of range; arguably they should fail with EOVERFLOW. as such, paying a small cost here on old kernels seems well-motivated. with this change, fchmodat itself is no longer blocking ports to new archs that lack the legacy syscalls. 2020-02-12T22:34:17Z Rich Felker dalias@aerifal.cx 2020-02-12T22:23:29Z urn:sha1:c9ebff4736128186121424364c1c62224b02aee3 because struct stat is no longer assumed to correspond to the structure used by the stat-family syscalls, it's not valid to make any of these syscalls directly using a buffer of type struct stat. commit 9493892021eac4edf1776d945bcdd3f7a96f6978 moved all logic around this change for stat-family functions into fstatat.c, making the others wrappers for it. but a few other direct uses of the syscall were overlooked. the ones in tmpnam/tempnam are harmless since the syscalls are just used to test for file existence. however, the uses in fchmodat and __map_file depend on getting accurate file properties, and these functions may actually have been broken one or more mips variants due to removal of conversion hacks from syscall_arch.h. as a low-risk fix, simply use struct kstat in place of struct stat in the affected places. 2019-10-28T23:26:52Z Rich Felker dalias@aerifal.cx 2019-08-02T01:33:57Z urn:sha1:0961bb94162896d358937e4979e5830f39818920 here _REDIR_TIME64 is used as an indication that there's an old ABI, and thereby the old time32 timespec fields of struct stat. keeping struct stat compatible and providing both versions of the timespec fields is done so that ftw/nftw does not need painful compat shims, and (more importantly) so that similar interfaces between pairs of libc consumers (applications/libraries) will be less likely to break when one has been rebuilt for time64 but the other has not.