Opened 5 years ago

Closed 5 years ago

#99 closed defect (fixed)

rebuilddb does not replace live database with temporary (fixed) database

Reported by: Lewis Rosenthal Owned by:
Priority: minor Milestone:
Component: rpm Version:
Severity: Keywords:
Cc:

Description

I've found:

[c:\]rpm --rebuilddb
error: temporary database /@unixroot/var/lib/rpm.rebuild already exists

Renaming rpm.rebuild and re-running works exactly once, leaving behind the temporary database dir, requiring manual cleanup.

Change History (6)

comment:1 Changed 5 years ago by Andy Willis

I am attempting to use --rebuilddb to see if I can clear up the issues with pthread and zlib where yum/rpm thinks that z.dll and pthr01.dll are not installed despite being there and the package being installed multiple times. I remove the packages and reinstall so that it is in just once and it will either fail to install due to lack of dependencies or install the packages again (which is how they become duplicated).
Anyhow, I created a rpm.rebuild which had a different and newer Packages file than in rpm. I had thought that I then had to manually replace the rpm folder with the rpm.rebuild if I wanted to use it.

comment:2 Changed 5 years ago by Lewis Rosenthal

Summary: rebuilddb does not clean up after itself (does not remove temporary database)rebuilddb does not replace live database with temporary (fixed) database

My initial assessment was incorrect. Thanks for making me look twice, Andy.

Indeed, starting off with:

 4-09-14  11:53         <DIR>      124  .
12-20-14   3:08         <DIR>      124  ..
12-19-14   2:51               0    124  .rpm.lock
12-19-14   3:23         688,128    124  Basenames
12-19-14   3:23          49,152    124  Conflictname
12-19-14   3:23         245,760    124  Dirnames
12-19-14   3:23         688,128    124  Filedigests
12-19-14   3:23          49,152    124  Group
12-19-14   3:23          32,768    124  Installtid
12-19-14   3:23          49,152    124  Name
12-19-14   3:23          49,152    124  Obsoletename
12-19-14   3:23       3,096,576    124  Packages
12-19-14   3:23          49,152    124  Providename
12-19-14   3:23          49,152    124  Provideversion
12-19-14   3:23          49,152    124  Requirename
12-19-14   3:23          49,152    124  Requireversion
12-19-14   3:23          49,152    124  Sha1header
12-19-14   3:23          49,152    124  Sigmd5
12-19-14   2:51          49,152    124  Triggername
       5,292,032 bytes in 17 files and 2 dirs

in @unixroot/var/lib/rpm, leaves off with the same contents after completion of rpm --rebuilddb, and then leaves:

12-20-14   3:08         <DIR>      124  .
12-20-14   3:08         <DIR>      124  ..
12-20-14   3:08         655,360    124  Basenames
12-20-14   3:08          49,152    124  Conflictname
12-20-14   3:08         245,760    124  Dirnames
12-20-14   3:08         688,128    124  Filedigests
12-20-14   3:08          49,152    124  Group
12-20-14   3:08          32,768    124  Installtid
12-20-14   3:08          49,152    124  Name
12-20-14   3:08          49,152    124  Obsoletename
12-20-14   3:08       3,112,960    124  Packages
12-20-14   3:08          49,152    124  Providename
12-20-14   3:08          49,152    124  Provideversion
12-20-14   3:08          49,152    124  Requirename
12-20-14   3:08          49,152    124  Requireversion
12-20-14   3:08          49,152    124  Sha1header
12-20-14   3:08          49,152    124  Sigmd5
       5,226,496 bytes in 15 files and 2 dirs

in @unixroot/var/lib/rpm.rebuild.

It is also not the presence of the .rpm.lock file in the rpm dir which is causing this.

comment:3 Changed 5 years ago by Yuri Dario

The macros dbpath had been changed probably to allow testing and never restored to default values. Now code uses PID to create a temporary directory. URPO allows moving files at process end, but the temp dir is still in place. URPO needs some work to implement delayed rmdir().

fix rebuild code. ticket#99.
Committed revision r483.

comment:4 Changed 5 years ago by Yuri Dario

comment:5 Changed 5 years ago by Yuri Dario

We cannot rename databases because they are still locked by DB4 engine; EACCESS cannot be handled by urpo rename() because this breaks DosReplaceModule? usage in other sources.

use urpo renameForce() to rename locked databases. ticket#99.
Committed revision r486.

comment:6 Changed 5 years ago by Yuri Dario

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.