[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: posix atime/ctime changes despite mtime being set
From: |
Sergey Poznyakoff |
Subject: |
Re: posix atime/ctime changes despite mtime being set |
Date: |
Mon, 31 Jul 2023 19:16:47 +0200 |
User-agent: |
MH (GNU Mailutils 3.15) |
Paul Eggert <eggert@cs.ucla.edu> ha escrit:
> This is why I suggested a new option to remove the subsecond components.
That surely will be useful, but in this particular case (in my opinion)
the question is rather how comes that tar was called with two different
sets of options. From reading opkg-build script, this can happen if it
was using different tar binaries (line 168) on subsequent invocations,
e.g. due to changes in $PATH between the two runs. Piotr, does that
seeseem plausible?
> I ran into a similar problem when generating the TZDB tarballs. These
> tarballs need to be portable to a wide variety of machines and so
> don't use any POSIX features: they're ustar format. The Makefile[1]
> has a set-timestamp.out rule that use a complex set of 'touch'
> commands to make sure all source files have their time-of-commit as
> their mtime, that all timestamps are a multiple of 1 second, that all
> files are at least 1 second newer than the files they depend on. This
> guarantees that all timestamps are reproducible. It would be nice if
> GNU Tar had an option to do all that, so that the Makefile didn't have
> to run 'touch' all the time. (I realize that I'm asking for a lot in
> the case of access to Git timestamps and to dependencies, but this is
> what TZDB needs.)
That's certainly possible. However, instead of using output of git
ls-files, I would rather propose something like
--set-mtime COMMAND
where COMMAND is any shell command that takes a file as its argument
and outputs a timestamp e.g. in seconds from the Epoch. What do you
think?
Regards,
Sergey
- Re: posix atime/ctime changes despite mtime being set, (continued)
- ODP: posix atime/ctime changes despite mtime being set, Piotr Łobacz, 2023/07/31
- Re: posix atime/ctime changes despite mtime being set, Sergey Poznyakoff, 2023/07/31
- Re: posix atime/ctime changes despite mtime being set, Paul Eggert, 2023/07/31
- Re: posix atime/ctime changes despite mtime being set, Piotr Łobacz, 2023/07/31
- Re: posix atime/ctime changes despite mtime being set, Piotr Łobacz, 2023/07/31
- Re: posix atime/ctime changes despite mtime being set, Sergey Poznyakoff, 2023/07/31
- Re: posix atime/ctime changes despite mtime being set, Paul Eggert, 2023/07/31
- Re: posix atime/ctime changes despite mtime being set,
Sergey Poznyakoff <=
- Re: posix atime/ctime changes despite mtime being set, Paul Eggert, 2023/07/31
- Re: posix atime/ctime changes despite mtime being set, Piotr Łobacz, 2023/07/31
- Re: posix atime/ctime changes despite mtime being set, Piotr Łobacz, 2023/07/31
- Re: posix atime/ctime changes despite mtime being set, Piotr Łobacz, 2023/07/31
- Re: posix atime/ctime changes despite mtime being set, Sergey Poznyakoff, 2023/07/25
- Re: posix atime/ctime changes despite mtime being set, Paul Eggert, 2023/07/25
- Re: posix atime/ctime changes despite mtime being set, Antonio Diaz Diaz, 2023/07/25