Re: duplicate binaries
*- On 5 Feb, Mitch Blevins wrote about "Re: duplicate binaries"
>>
>> With the output of the ls commands here, note the sizes of the files. I have
>> actually checked, and the files are identical except for their names.
>>
>> $ ls -l /bin/*grep /usr/bin/*grep
>> -rwxr-xr-x 3 root root 75728 Apr 27 1998 /bin/egrep
>> -rwxr-xr-x 3 root root 75728 Apr 27 1998 /bin/fgrep
>> -rwxr-xr-x 3 root root 75728 Apr 27 1998 /bin/grep
>> -rwxr-xr-x 1 root root 12992 Jan 3 10:23 /usr/bin/rgrep
>> -rwxr-xr-x 3 root root 1375 Jan 27 21:51 /usr/bin/zegrep
>> -rwxr-xr-x 3 root root 1375 Jan 27 21:51 /usr/bin/zfgrep
>> -rwxr-xr-x 3 root root 1375 Jan 27 21:51 /usr/bin/zgrep
>>
>> The first three, egrep, fgrep, and grep are all identical files. The same is
>> true for zegrep, zfgrep and zgrep.
>>
>> This is seen again with gzip, gunzip, uncompress, and zcat.
>> $ cd /bin; ls -l gzip gunzip uncompress zcat
>> -rwxr-xr-x 4 root root 44972 Jan 27 21:51 gunzip
>> -rwxr-xr-x 4 root root 44972 Jan 27 21:51 gzip
>> -rwxr-xr-x 4 root root 44972 Jan 27 21:51 uncompress
>> -rwxr-xr-x 4 root root 44972 Jan 27 21:51 zcat
>>
>> Here is another instance:
>> $ cd /usr/bin; ls -l perl perl5.00404 suidperl sperl5.00404
>> -rwxr-xr-x 2 root root 491820 Feb 3 02:58 perl
>> -rwxr-xr-x 2 root root 491820 Feb 3 02:58 perl5.00404
>> -rwsr-xr-x 2 root root 493132 Feb 3 02:58 sperl5.00404
>> -rwsr-xr-x 2 root root 493132 Feb 3 02:58 suidperl
>>
>> The files are identical except for their names. There are probably a bunch
>> of other packages that have this, too. Shouldn't there be symlinks instead
>> of having multiple copies of everything?
>
> Okay, now I understand.
> I thought you meant that you had both a /bin/grep and a /usr/bin/grep.
>
> It seems to me that these should be symlinks. Maybe there's a valid
> reason for having them distinct *shrugs*.
> File a bug against the packages they are in and at least the issue
> will be addressed.
>
Notice the second filed in the listings above, before the owner. That
is the number of hard links the files have. I.e. they are the same
file and do not take up any additional space. Another way to see that
they are the same files is to add the inode to the lists 'ls -il':
258316 -rwxr-xr-x 2 root root 491964 Jun 5 1998 perl
258316 -rwxr-xr-x 2 root root 491964 Jun 5 1998 perl5.00404
96269 45 -rwxr-xr-x 4 root root 44924 Jan 22 13:00 gunzip*
96269 45 -rwxr-xr-x 4 root root 44924 Jan 22 13:00 gzip*
96269 45 -rwxr-xr-x 4 root root 44924 Jan 22 13:00 uncompress*
96269 45 -rwxr-xr-x 4 root root 44924 Jan 22 13:00 zcat*
96266 75 -rwxr-xr-x 3 root root 75728 Apr 27 1998 /bin/egrep*
96266 75 -rwxr-xr-x 3 root root 75728 Apr 27 1998 /bin/fgrep*
96266 75 -rwxr-xr-x 3 root root 75728 Apr 27 1998 /bin/grep*
258969 2 -rwxr-xr-x 3 root root 1375 Jan 22 13:00 /usr/bin/zegrep*
258969 2 -rwxr-xr-x 3 root root 1375 Jan 22 13:00 /usr/bin/zfgrep*
258969 2 -rwxr-xr-x 3 root root 1375 Jan 22 13:00 /usr/bin/zgrep*
^^^^^^
inode #
All the files that you are concerned about have the same inode # and
are thus the same file with different name and thus do NOT take up
extra space on the disk.
>From 'info ln'
A "hard link" is another name for an existing file; the link and the
original are indistinguishable. (Technically speaking, they share the
same inode, and the inode contains all the information about a
file--indeed, it is not incorrect to say that the inode *is* the file.)
On all existing implementations, you cannot make a hard links to
directories, and hard links cannot cross filesystem boundaries. (These
restrictions are not mandated by POSIX, however.)
"Symbolic links" ("symlinks" for short), on the other hand, are a
special file type (which not all kernels support; in particular, system
V release 3 (and older) systems lack symlinks) in which the link file
actually refers to a different file, by name. When most operations
(opening, reading, writing, and so on) are passed the symbolic link
file, the kernel automatically "dereferences" the link and operates on
the link file itself, rather than on its target.
So don't file bug reports.
Brian
---------------------------------------------------------------------
"Never criticize anybody until you have walked a mile in their shoes,
because by that time you will be a mile away and have their shoes."
- unknown
Mechanical Engineering bservis@usa.net
Purdue University http://www.ecn.purdue.edu/~servis
---------------------------------------------------------------------
Reply to: