Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
+++ This bug was initially created as a clone of Bug #1458008 +++
If the mtimes of two files differ by less than 1 second while the component of secs in the same in both timestamps, the command "[ file1 -nt/-ot file2 ]" gives a wrong result. Here '[' is the bash builtin.
Version-Release number of selected component (if applicable):
bash-4.3.43-4.fc25.x86_64
bash-4.2.46-20.el7_2.x86_64 (RHEL 7.3)
Steps to Reproduce:
$ while true; do touch a; sleep 0.6; touch b; stat a b|grep Modify; [ b -nt a ] && echo test_cmd_ok; echo; done
Actual results:
Modify: 2017-06-01 19:31:05.699921567 +0200
Modify: 2017-06-01 19:31:06.303918131 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:06.309918097 +0200
Modify: 2017-06-01 19:31:06.913914657 +0200
Modify: 2017-06-01 19:31:06.918914629 +0200
Modify: 2017-06-01 19:31:07.522911187 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:07.527911159 +0200
Modify: 2017-06-01 19:31:08.132907713 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:08.137907685 +0200
Modify: 2017-06-01 19:31:08.742904235 +0200
Modify: 2017-06-01 19:31:08.748904201 +0200
Modify: 2017-06-01 19:31:09.351900765 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:09.357900731 +0200
Modify: 2017-06-01 19:31:09.961897294 +0200
Modify: 2017-06-01 19:31:09.967897260 +0200
Modify: 2017-06-01 19:31:10.570893817 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:10.576893783 +0200
Modify: 2017-06-01 19:31:11.180890345 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:11.186890311 +0200
Modify: 2017-06-01 19:31:11.789886880 +0200
Modify: 2017-06-01 19:31:11.795886846 +0200
Modify: 2017-06-01 19:31:12.399883404 +0200
test_cmd_ok
Expected results:
Modify: 2017-06-01 19:31:05.699921567 +0200
Modify: 2017-06-01 19:31:06.303918131 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:06.309918097 +0200
Modify: 2017-06-01 19:31:06.913914657 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:06.918914629 +0200
Modify: 2017-06-01 19:31:07.522911187 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:07.527911159 +0200
Modify: 2017-06-01 19:31:08.132907713 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:08.137907685 +0200
Modify: 2017-06-01 19:31:08.742904235 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:08.748904201 +0200
Modify: 2017-06-01 19:31:09.351900765 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:09.357900731 +0200
Modify: 2017-06-01 19:31:09.961897294 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:09.967897260 +0200
Modify: 2017-06-01 19:31:10.570893817 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:10.576893783 +0200
Modify: 2017-06-01 19:31:11.180890345 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:11.186890311 +0200
Modify: 2017-06-01 19:31:11.789886880 +0200
test_cmd_ok
Modify: 2017-06-01 19:31:11.795886846 +0200
Modify: 2017-06-01 19:31:12.399883404 +0200
test_cmd_ok
Additional info:
Note that the '[' command from coreutils works as expected.
A quick recursive grep of the filesystem reveals a certain number of instances of "[ -nt/-ot" in files belonging to some common packages like elfutils, git, grub as well as sendmail and postfix (at least in RHEL). I came accross this bug while debugging weird behavior of /etc/mail/make (part of sendmail, called e.g. from its systemd unit file) which wouldn't refresh the main config file sometimes if called in fast repetition.
As far as RHEL is concerned, this issue might be of interest to the developers of packages that call "[ -nt/-ot". I'm at least adding CC: sendmail/posftix's Jaroslav Skarvada.
--- Additional comment from Kamil Dudka on 2017-06-02 08:57:37 CEST ---
Thank you for reporting the bug!
This seems to be caused by the get_stat_mtime_ns() function returning 0 because of STAT_TIMESPEC and STAT_TIMESPEC_NS not being defined.
The autoconf tests check for sub-second precision for atime only, so we end up with HAVE_STRUCT_STAT_ST_ATIMESPEC_TV_NSEC not being defined. But it doe not mean that we cannot obtain mtime with sub-second precision. In fact, strace shows that bash gets precise enough data but, if I stop gdb in timespec_cmp(), the tv_nsec fields are always zero.
Note that this bug is specific to bash. ksh, zsh, and coreutils seem compare mtime with sub-second precision.
After further consideration I'm suggesting that this be considered for RHEL. I do not know if this is a regression or not, but if it is, this could be a critical issue to fix. The issue could also have potential security implications. (Thanks to Jan Ščotka for pointing this out.)
Regardless of the regression status, this might simply be of interest to a large audience, because the feature in question could potentially be used in a large number of scripts in various packages as well as custom scripts on servers.
(In reply to Roman Žilka from comment #2)
> After further consideration I'm suggesting that this be considered for RHEL.
> I do not know if this is a regression or not, but if it is, this could be a
> critical issue to fix.
The burden is usually on the reporter to prove that a bug is a regression...
I tried bash-4.2.45-5.el7 tagged rhel-7.0 and it gives me the same behavior.
> The issue could also have potential security implications.
Each single bug could have potential security implications :) If you are aware of any attack vector, please contact Product Security via appropriate channels.
> Regardless of the regression status, this might simply be of interest to a
> large audience, because the feature in question could potentially be used in
> a large number of scripts in various packages as well as custom scripts on
> servers.
Note that not all file systems support sub-second precision for mtime anyway.
So scripts relying on that are not portable by design.
This bug has a pretty straight-forward workaround: use /usr/bin/[ instead of [