Bug 417731 - rpm counts file links number incorrectly
rpm counts file links number incorrectly
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-10 02:23 EST by Sergey Rogozhkin
Modified: 2009-07-14 12:11 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 12:11:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix file links counting (2.25 KB, patch)
2007-12-10 02:23 EST, Sergey Rogozhkin
no flags Details | Diff

  None (edit)
Description Sergey Rogozhkin 2007-12-10 02:23:54 EST
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.
Comment 1 Sergey Rogozhkin 2007-12-10 02:23:54 EST
Created attachment 282501 [details]
Fix file links counting
Comment 2 Jeff Johnson 2007-12-10 19:52:58 EST
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.

Comment 3 Sergey Rogozhkin 2007-12-12 03:14:02 EST
> 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.

Comment 4 Jeff Johnson 2007-12-12 23:35:10 EST
Can you supply an example where it matters?
Comment 5 Jeff Johnson 2007-12-12 23:40:26 EST
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.

Comment 6 Sergey Rogozhkin 2007-12-13 02:08:56 EST
> 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.
Comment 7 Sergey Rogozhkin 2007-12-13 02:32:41 EST
(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.
Comment 8 Bug Zapper 2008-05-14 00:08:51 EDT
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
Comment 9 Bug Zapper 2009-06-09 19:16:33 EDT
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
Comment 10 Bug Zapper 2009-07-14 12:11:15 EDT
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.

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