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 77002 - DB_File resets file timestamps when it should not
Summary: DB_File resets file timestamps when it should not
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: perl
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Warren Togami
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-30 20:12 UTC by Need Real Name
Modified: 2007-04-18 16:48 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-28 07:07:08 UTC


Attachments (Terms of Use)

Description Need Real Name 2002-10-30 20:12:18 UTC
Description of Problem:
(2002.10.30, 14:38)

I have a problem with Perl and DB_File under RedHat 7.3. This problem
occurs with programs which used to run fine in 7.1.

Whenever I open a dbm file using DB_File and with 0444 access
permission (read only), the datestamp of the file is updated, even
though no change was made to the file! The following Perl script
provokes that problem on my system (as well as on a friend's system
which uses 7.3 as well).

Are we the only one with this problem? Is there a solution?

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


How Reproducible:
#! /usr/bin/perl
use DB_File;
$file = $ARGV[0];
if ( not $file ) { print "..Syntax: $0 filename\n"; exit; }
if (not dbmopen %basedbm,$file,0444) { print "..Can't open file $file\n"; 
exit; }
$n = scalar keys %basedbm;
dbmclose %basedbm;
print "$n records\n";

This only opens the file; it does not change it. Yet, it changes the timestamp 
on the file.

Steps to Reproduce:
1. 
2. 
3. 

Actual Results:
Timestamp change.

Expected Results:
No timestamp change.

Additional Information:

Comment 1 Chip Turner 2002-11-06 16:38:25 UTC
can you confirm the file on disk remained the same?  it is possibly berkeley db
doing some housekeeping on the file itself.  the md5sum program can determine if
a change takes place between invocations

Comment 2 Chip Turner 2002-11-06 16:41:23 UTC
(moving to perl component; it isn't actually a DBI bug itself)

Comment 3 Warren Togami 2005-05-28 07:07:08 UTC
Closing due to lack of activity and likely fixed in modern perl.  If this is
still an issue in RHEL4, FC3 or FC4 please open a new bug with new test
information and exact versions of packages.



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