Rpm uses the following code for file links number counting (e.g. while executing -qlv request) int_32 rpmfiFNlink(rpmfi fi) { int_32 nlink = 0; if (fi != NULL && fi->i >= 0 && fi->i < fi->fc) { /* XXX rpm-2.3.12 has not RPMTAG_FILEINODES */ /*@-boundsread@*/ if (fi->finodes && fi->frdevs) { int_32 finode = fi->finodes[fi->i]; int_16 frdev = fi->frdevs[fi->i]; int j; for (j = 0; j < fi->fc; j++) { if (fi->frdevs[j] == frdev && fi->finodes[j] == finode) nlink++; } } /*@=boundsread@*/ } return nlink; } There are at least two reasons why this code is invalid: 1. fi->frdevs is a pointer to uint_16, while frdev is int_16. Due to integer propagation (fi->frdevs[j] == frdev) value will be 0 even for j = fi->i, if fi->rfdevs[fi->i] has an upper bit set. As an example, rpm will show links number 0 for any device file with major number > 127. 2. There is no any sense with using fi->frdevs here. rpmfiFNlink must check pair (inode number,device id) of file, while it actually check (inode number, st_rdev) pair. Attached patch deals with 2nd issue (but also fix types used). I'am not an rpm expert, so maybe I am totally wrong.
Created attachment 282501 [details] Fix file links counting
You're correct that the no. of links counting is feeble. First of all device major/minor has been bigger than 16 bits in linux for years. RPMTAG_FILERDEVS (which originally was populated from st->st_rdev on the build system) is the only available information in pkgs headers from which a link count might be estimated. What is totally bogus is including st->st_rdev from the build machine, which likely has almost nothing to do with the file systems and device id's on the install system. The unsigned <-> signed comparison problems are fixed in rpm-5.0.
> RPMTAG_FILERDEVS (which originally was populated from st->st_rdev on the build > system) is the only available information in pkgs headers from which a link > count might be estimated. > > What is totally bogus is including st->st_rdev from the build machine, > which likely has almost nothing to do with the file systems and device > id's on the install system. No. Rpm packages (at least produced by rpm-4.4.x) have RPMTAG_FILERDEVS and RPMTAG_FILEDEVICES info in their headers. This info is populated from st->st_rdev and st->st_dev stat structure fields correspondingly. Use of RPMTAG_FILERDEVS info (st_rdev) for links counting is _absolutely_ senselessly, while RPMTAG_FILEDEVICES and RPMTAG_FILEINODES info can give us a good estimation for links number on target system.
Can you supply an example where it matters?
The entire computation is senseless when inter-pkg hard links, or non-packaged links are present. The value computed for st_nlinks is just plain wrong in those cases, a far worse problem than whether st_dev or st_rdev is used.
> Can you supply an example where it matters? I had noticed this problem while building rpm packages on exotic linux system, which really put garbage into st_rdev stat field for non-device files. The observed results (take into account signed <-> unsigned comparison also) were very strange: rpm -qlpv shows files with links number 0 and so on. This situation induce me to fix my version of rpm for me and write this report. So, I really can't supply an example to you.
(In reply to comment #5) > The entire computation is senseless when inter-pkg hard links, or non-packaged > links are present. The value computed for st_nlinks is just plain wrong in those > cases, a far worse problem than whether st_dev or st_rdev is used. > > Yes, You are right, the whole idea is doubtful, but this is rpm design problem. We work with rpm as it is, and my idea was only to make situation with link counting slightly less incorrect.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.