On 5/25/2020 12:47 PM, Fergus Daly via Cygwin wrote:
It looks to me that /etc/setup/timestamp is updated by the last successful setup
(upgrade?) run, and contains a copy of the selected mirror's setup.ini
setup_timestamp field as of the last successful setup (upgrade?) run, a few
hours earlier than the last successful setup (upgrade?) run.

Thank you for this.
I can't really think of anything to say other than repeat my observation, 
today, of altered practice.
Since as long as I can remember (and I mean - a matter of years) a successful 
upgrade of Cygwin32
(implementing the current version of setup-x86.exe currently 2.904
and pulling in the latest version of setup.ini found at {source}/Cygwin/x86/)
has concluded with
(i) a glitch-free accounting in /var/log/setup.log(.full), together with
(ii) a revision of the file /etc/setup/timestamp
which reflects the timestamp line in the aforementioned setup.ini file.
(And other things too, quite apart from any updates to the Cygwin provision - 
e.g. an updated /etc/setup/installed.db file.)

What I have observed, twice now (earlier today using setup.ini incorporating 
timestamp 1590343308 and now using the latest setup.ini incorporating timestamp 
1590407755) is that event (ii) is failing: the file /etc/setup/timestamp is not 
updated - and if it isn't there at all, it is not created.

I'm not seeing any change in behavior on my system. I just deleted /etc/setup/timestamp and ran setup. A new /etc/setup/timestamp was created, with contents 1590430423. This matches the value in the downloaded setup.ini file:

  setup-timestamp: 1590430423

Do you see any error messages involving /etc/setup/timestamp in the setup log files in /var/log?

Ken
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

Reply via email to