On Haiku, I see these test failures:
FAIL: test-futimens
===
../../gltests/test-futimens.h:123: assertion 'get_stat_atime_ns (&st1) ==
get_stat_atime_ns (&st2)' failed
Abort
FAIL test-futimens (exit status: 149)
FAIL: test-utime
../../gltes
modules/lchown-tests (Depends-on): Likewise.
> * modules/stat-time-tests (Depends-on): Likewise.
> * modules/utime-tests (Depends-on): Likewise.
> * modules/utimens-tests (Depends-on): Likewise.
> * modules/utimensat-tests (Depends-on): Likewise.
These two module d
* modules/fdutimensat-tests (Depends-on): Likewise.
* modules/futimens-tests (Depends-on): Likewise.
* modules/lchown-tests (Depends-on): Likewise.
* modules/stat-time-tests (Depends-on): Likewise.
* modules/utime-tests (Depends-on): Likewise.
* modules/utimen
On 2024-08-10 17:57, Collin Funk wrote:
All seem to have Y2K:
Yes, and that's the correct value. Thanks to both you and Bruno for
reporting it. I installed the attached.From 8fa1fba5dab1a126c25e534867f653359039d177 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 10 Aug 2024 21:47:07 -07
Hi Paul, Bruno,
Bruno said:
> Today, one of the continuous integrations (on Debian 10, with gcc)
> fails:
My host system (Fedora 40 BTRFS) fails the same three tests but in
different places:
test-utimens.h:197: assertion 'st2.st_atime == BILLION' failed
FAIL test-fdutimensat (exit statu
Paul Eggert wrote:
> tests/test-utimens.h | 46 +---
Today, one of the continuous integrations (on Debian 10, with gcc) fails:
FAIL: test-fdutimensat
==
test-utimens.h:197: assertion 'st2.st_atime == BILLION' failed
Stack trace:
0x594d65
Eggert
+
+ test-utime: port to noatime file systems
+ Problem encountered on Ubuntu 24.04 zfs mounted noatime.
+ * tests/test-fdutimensat.c (main):
+ * tests/test-futimens.h (test_futimens):
+ * tests/test-lutimens.h (test_lutimens):
+ * tests/test-utime.c
> >>> conftest.c:491:23: error: implicit declaration of function 'utime' is
> >>> invalid in C99 [-Werror,-Wimplicit-function-declaration]
> >>> if (!utime ("conftest.tmp/", NULL))
> >>>
igure, wget 1.12.1 prints this:
checking whether utime handles trailing slashes on files... no
config.log contains this:
configure:49368: checking whether utime handles trailing slashes on files
configure:49414: ccache /usr/bin/clang -o conftest -DNDEBUG -pipe -Os
-Werror=implicit-function-declar
Martin Storsjö wrote:
> FAIL: test-utime
When I add an autoconf test for the trailing slash handling in utime(), I get:
checking whether utime handles trailing slashes on files... no
along with
checking whether lstat correctly handles trailing slash... no
checking whether stat hand
Hi Max,
> $ docker run -it --rm -v $(pwd):/mnt debian:latest tar xvf /mnt/test.tar -C
> /mnt
>
> The last step fails with:
>
> tar: gnulib-bug-symlinks/2: Cannot utime: No such file or directory
>
> The commit that caused this error to occur is
> http://git.savan
Thanks for reporting the problem. This appears to be due to a bug in the macOS
implementation of utimensat; see:
https://github.com/rfjakob/gocryptfs/issues/229
I don't use macOS so it'd be helpful if you could check a possible workaround
(attached). If this patch doesn't work for you, please
HI all,
when using bind mounts and trying to extract a tar archive containing
symlinks to it the extraction fails with "Cannot utime: No such file or
directory". This only appears to happen on macOS (I'm using 10.14.5 and
Docker Desktop 2.0.0.3).
Here are the steps to reproduce
2018-08-06 Bruno Haible
getopt-posix, utime-h: Ensure the .h file gets regenerated when needed.
* modules/getopt-posix (Makefile.am): Add Makefile dependency for
getopt.h.
* modules/utime-h (Makefile.am): Add Makefile dependency for utime.h.
diff --git a
The modules iconv-h, monetary, utime-h install their header file only
conditionally. But that condition needs to evaluate to true if module
'posixcheck' is in use. This series of patches fixes it.
2018-08-05 Bruno Haible
utime-h: Generate header file when module 'po
And this adds tests for 'utime'.
2017-04-30 Bruno Haible
utime-tests: New module.
* tests/test-utime.c: New file, based on tests/test-utimens.h.
* tests/test-utimens-common.h: Include .
* modules/utime-tests: New file.
diff --git a/modules/uti
This patch add a module 'utime'. The original _utime function on native Windows
has a behaviour that depends on the time zone, which is nonsense (see
https://lists.gnu.org/archive/html/bug-gnulib/2017-04/msg00164.html ).
2017-04-29 Bruno Haible
utime: New module.
A simple patch to make use of the new module 'utime-h'.
2017-04-29 Bruno Haible
Make use of module 'utime-h'.
* modules/copy-file (Depends-on): Add utime-h.
* lib/copy-file.c: Assume that exists.
* m4/copy-file.m4 (gl_COPY_F
Before implementing an override for the utime() function, we need the
header file. This patch provides it.
2017-04-29 Bruno Haible
utime-h: New module.
* m4/utime_h.m4: New file.
* lib/utime.in.h: New file.
* modules/utime-h: New file.
* doc/posix
ll reasonably
easy to maintain code for). But I won't write a utime replacement for
Solaris, because an interface that only offers 1 second granularity is
pointless.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
orrow if no one objects.
>
> Sounds good to me.
>
>> +On some old platforms (Sequent), @code{utime (file, NULL)} fails to set the
>> +file's timestamp to the current time.
>
> I'm assuming nobody cares about Sequent any more. If anyone does, it is
> in th
Simon Josefsson wrote:
> Jim, the utime module says:
>
> Notice:
> This module is obsolete. It can be removed on 2010-01-01.
>
> Why is it obsolete? Should we remove it now? The code looks useful to
> me, but I may be missing something. I cannot find anything in NEWS or
t; +On some old platforms (Sequent), @code{utime (file, NULL)} fails to set the
> +file's timestamp to the current time.
I'm assuming nobody cares about Sequent any more. If anyone does, it is
in the git history.
> On some platforms, this function mis-handles trailing slash:
>
Jim, the utime module says:
Notice:
This module is obsolete. It can be removed on 2010-01-01.
Why is it obsolete? Should we remove it now? The code looks useful to
me, but I may be missing something. I cannot find anything in NEWS or
doc/posix-functions/utime.texi to explain this either
Ronan MELENNEC <[EMAIL PROTECTED]> writes:
> --- gzip-1.3.6/lib/utimens.c.orig 2006-09-14 00:38:14.0 +0200
> +++ gzip-1.3.6/lib/utimens.c 2006-12-05 10:25:35.0 +0100
> @@ -93,6 +93,12 @@
>else
> t = NULL;
>
> + /*
> + * TO BE REVIEWED (usefulness and portability)
Paul Eggert wrote:
> "Derek R. Price" <[EMAIL PROTECTED]> writes:
>
>> Since the utime module only switches on the result of
>> AC_FUNC_UTIME_NULL, and the Autoconf 2.60 documentation labels
>> AC_FUNC_UTIME_NULL as obsolescent for lack of practical porting
"Derek R. Price" <[EMAIL PROTECTED]> writes:
> Since the utime module only switches on the result of
> AC_FUNC_UTIME_NULL, and the Autoconf 2.60 documentation labels
> AC_FUNC_UTIME_NULL as obsolescent for lack of practical porting targets,
> would be okay to remove
Since the utime module only switches on the result of
AC_FUNC_UTIME_NULL, and the Autoconf 2.60 documentation labels
AC_FUNC_UTIME_NULL as obsolescent for lack of practical porting targets,
would be okay to remove the utime module from GNULIB?
This would mean removing lib/utime.c, m4/utime.m4
Sergey Poznyakoff <[EMAIL PROTECTED]> writes:
> Hmm, now I see a better solution: to list m4/utimbuf.m4 in Files
> section of modules/utimens.
Right you are. I installed that.
2005-09-08 Paul Eggert <[EMAIL PROTECTED]>
* modules/utimens (Files): Add m4/utimbuf.m4, since
m4/ut
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Sergey Poznyakoff <[EMAIL PROTECTED]> writes:
>
> > The module utimens depends on utime,
>
> Could you please explain why?
Because m4/utimens.m4 AC_REQUIREs gl_CHECK_TYPE_STRUCT_UTIMBUF,
which is defined in m4/utimbu
Sergey Poznyakoff <[EMAIL PROTECTED]> writes:
> The module utimens depends on utime,
Could you please explain why?
As I understand it, the utime module is needed only for ancient
4.3BSD-based systems where the utime function mishandles NULL
arguments. Such systems are no longer in
The module utimens depends on utime, however this dependency is not
listed in modules/utimens. This can be fixed by the following patch:
Index: modules/utimens
===
RCS file: /cvsroot/gnulib/gnulib/modules/utimens,v
retrieving
32 matches
Mail list logo