Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 79429 - zoneinfo files overwritten or truncated to 0, but not after timeconfig is ran
Summary: zoneinfo files overwritten or truncated to 0, but not after timeconfig is ran
Keywords:
Status: CLOSED DUPLICATE of bug 66655
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: dateconfig
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-12-11 17:07 UTC by Gage
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-12-11 17:07:46 UTC


Attachments (Terms of Use)

Description Gage 2002-12-11 17:07:36 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
When cycling timezones via dateconfig (from one timezone to another, then back
again), the original timezone file becomes 0 length.  $date as a result defaults
to give UTC as the timezone.

However, after I then played with /usr/sbin/timeconfig I am no longer able to
duplicate the error.

I tried this on a couple different computers (RH7.3, dateconfig-0.7.5-7) and it
appears to be consistent.

Version-Release number of selected component (if applicable):
dateconfig-0.7.5-7

How reproducible:
Always

Steps to Reproduce:
1 - change timezone via dateconfig (from AST to PST)
2 - change it back (from PST to AST)

--> /usr/share/zoneinfo/Canada/Atlantic becomes 0 length...

3 - replace corrupted timezone file with the original
4 - run timeconfig (make changes or don't, doesn't matter) and save
5 - change timezone via dateconfig (from AST to PST)
6 - change it back (from PST to AST)

--> /usr/share/zoneinfo/Canada/Atlantic unaltered...



Actual Results:  timezone file is altered, then truncated.  After timeconfig,
all is happy...

Expected Results:  Files stay consistent

Additional info:

[root@localhost Canada]# date
Wed Dec 11 12:44:43 AST 2002
[root@localhost Canada]# ll /usr/share/zoneinfo/Canada/Atlantic
-rw-r--r--    3 root     root         1237 Dec 11 11:24
/usr/share/zoneinfo/Canada/Atlantic
[root@localhost Canada]# dateconfig
Shutting down ntpd:                                        [FAILED]
[root@localhost Canada]# date
Wed Dec 11 08:45:09 PST 2002
[root@localhost Canada]# ll /usr/share/zoneinfo/Canada/Atlantic
-rw-r--r--    3 root     root         1020 Dec 11 08:45
/usr/share/zoneinfo/Canada/Atlantic
[root@localhost Canada]# dateconfig
Shutting down ntpd:                                        [FAILED]
[root@localhost Canada]# date
Wed Dec 11 16:45:37 UTC 2002
[root@localhost Canada]# ll /usr/share/zoneinfo/Canada/Atlantic
-rw-r--r--    3 root     root            0 Dec 11 16:45
/usr/share/zoneinfo/Canada/Atlantic

(replaced Atlantic to original form...)

[root@localhost Canada]# timeconfig
[root@localhost Canada]# date
Wed Dec 11 12:47:44 AST 2002
[root@localhost Canada]# ll /usr/share/zoneinfo/Canada/Atlantic
-rw-r--r--    3 root     root         1237 Dec 11 12:47
/usr/share/zoneinfo/Canada/Atlantic
[root@localhost Canada]# dateconfig
Shutting down ntpd:                                        [FAILED]
[root@localhost Canada]# date
Wed Dec 11 08:48:13 PST 2002
[root@localhost Canada]# ll /usr/share/zoneinfo/Canada/Atlantic
-rw-r--r--    3 root     root         1237 Dec 11 08:47
/usr/share/zoneinfo/Canada/Atlantic
[root@localhost Canada]# dateconfig
Shutting down ntpd:                                        [FAILED]
[root@localhost Canada]# date
Wed Dec 11 12:48:48 AST 2002
[root@localhost Canada]# ll /usr/share/zoneinfo/Canada/Atlantic
-rw-r--r--    3 root     root     1237 Dec 11 12:47
/usr/share/zoneinfo/Canada/Atlantic

Comment 1 Brent Fox 2002-12-11 20:21:08 UTC

*** This bug has been marked as a duplicate of 66655 ***


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