Pointless unlink-link in strip_execs?

Pointless unlink-link in strip_execs?

[Kaz Kylheku]

Hi,

I'm looking at meta/lib/oe/package.py, function strip_execs, under Yocto 
2.5.

It has this tidbit:

                     if s.st_ino in inodes:
                         os.unlink(file)                     # <--- of 
interest
                         os.link(inodes[s.st_ino], file)     #
                     else:
                         # break hardlinks so that we do not strip the 
original.
                         inodes[s.st_ino] = file
                         bb.utils.copyfile(file, file)
                         elffiles[file] = elf_file

If s.st_ino is in the inodes dictionary, doesn't that mean that the 
paths
inodes[s.st_ino] and file are already hard links to the same object?

In other words, those two link and unlink lines don't achieve anything?

Also, if the file is not in the inode list now, it could be unique.
Why would we waste time copying a file that might turn out unique? Don't 
we want
the logic to be "if we have seen this inode already, then copy-on-write
the file?"

Also if the file is unique and we do copyfile(file, file), then the 
original
inode is gone, isn't it? The original s.st_ino is garbage (and may be 
re-used
by the filesystem for some new, unrelated object), yet we continue to 
have
an entry for it in inodes[s.st_ino].

I'm probably missing some contextual subtlety, but it seems worth a 
review.

Cheers ...

Re: Pointless unlink-link in strip_execs?

[Richard Purdie]

On Fri, 2019-09-06 at 11:52 -0700, Kaz Kylheku wrote:
> Hi,
> 
> I'm looking at meta/lib/oe/package.py, function strip_execs, under
> Yocto 
> 2.5.
> 
> It has this tidbit:
> 
>                      if s.st_ino in inodes:
>                          os.unlink(file)                     # <---
> of 
> interest
>                          os.link(inodes[s.st_ino], file)     #
>                      else:
>                          # break hardlinks so that we do not strip
> the 
> original.
>                          inodes[s.st_ino] = file
>                          bb.utils.copyfile(file, file)
>                          elffiles[file] = elf_file
> 
> If s.st_ino is in the inodes dictionary, doesn't that mean that the 
> paths
> inodes[s.st_ino] and file are already hard links to the same object?
> 
> In other words, those two link and unlink lines don't achieve
> anything?

I think its more subtle than this.

It will be in that inodes list if we already want to break hardlinks to
the copy having gone through the "else" section once before already. We
want one copy and all the hardlinks pointing to that copy.

The reason is so that we have one stripped copy and in our packaged
data, all copies hardlink to that copy.

Cheers,

Richard