Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 17414 - Invalid timestamp on file creation
Invalid timestamp on file creation
Product: Red Hat Linux
Classification: Retired
Component: bash (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Depends On:
  Show dependency treegraph
Reported: 2000-09-11 15:15 EDT by Need Real Name
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-05-14 00:09:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2000-09-11 15:15:01 EDT
when I run the 'date; command I get the following output: Mon Sep 11 15:12:45 EDT 2000; however when I create a file I get  15 Sep 11 19:13 
for the file creation date.  I do NOT have the hardware clock set to GMT.
Comment 1 Need Real Name 2000-09-12 08:53:45 EDT
I did not notice this with RedHat 6.1, and they both have the same timezone, 
and are NOT set to use GMT.
Comment 2 Bill Nottingham 2000-09-12 17:47:23 EDT
What does 'zdump /etc/localtime say'?
Comment 3 Need Real Name 2000-09-13 07:09:24 EDT
[root@linux tim]# zdump /etc/localtime
/etc/localtime  Wed Sep 13 07:04:50 2000 EDT
[root@linux tim]# touch test
[root@linux tim]# l test
-rw-r--r--   1 1000     1001           15 Sep 13 11:05 test
[root@linux tim]#

NOTE: 'l' is just an alias of 'ls -l'  The zdump gives the corest time; 
however, when I create a file I still get the invalid time.
Comment 4 Need Real Name 2000-09-14 11:14:19 EDT
/sbin/clock shows the propper time (the time on the hardware clock), but 
setting it to EST shouldn't change that should it.
Comment 5 Bernhard Rosenkraenzer 2000-10-01 18:33:34 EDT
I can't reproduce this... Does it still occur in 7.0?
Comment 6 Need Real Name 2000-10-02 09:58:44 EDT
I can not run 7.0 unless you nativley support the DPT SmartRAID V driver.  I 
have to wait for DPT to put out a Red Hat 7.0 driver.  I think I found the 
problems anyway.  How do I reverse the "System uses UTC" option that you select 
in the installation.
Comment 7 libruno 2001-02-23 14:44:42 EST
I start seeing this problem on our RH 6.2 system:

$ date
Fri Feb 23 11:43:14 PST 2001
$ touch /tmp/tmpfile
$ ls -l /tmp/tmpfile
-rw-r--r--    1 root     root            0 Feb 23 19:43 /tmp/tmpfile
Comment 8 Need Real Name 2001-03-28 14:42:26 EST
I have the same problem on my 6.2 machine.  I've tried everything, but the 
timestamps are still wrong.  It looks like 'ls' is not using the timezone and 
reporting the time as UTC.  This is an old bug, is anyone working on it?

# date >foo
# ls -l foo
-rw-r--r--   1 root     root           29 Mar 28 19:39 foo
# cat foo
Wed Mar 28 12:39:14 MST 2001
Comment 9 Need Real Name 2001-05-14 00:09:27 EDT
I noticed this same behavior on a 6.2 machine.  I checked a 2nd 6.2 machine and 
it behaved correctly.  So I started looking deeper and found that we had a root 
kit on the machine behaving incorrectly.  The root kit replaced ls, find, 
netstat, login, and many others.  So if you experience this behavior, start 
looking for a root kit.   Just a word to the wise, don't trust your machine to 
tell you what ports are open.  If netstat and lsof are trojans, they won't help 
you identifiy open ports (as was our case).

Comment 10 Bernhard Rosenkraenzer 2001-05-17 16:40:08 EDT
Assuming the root kit was responsible since I still can't reproduce this 

Note You need to log in before you can comment on or make changes to this bug.