On 08/02/2016 06:55 AM, Richard Purdie wrote:
On Mon, 2016-08-01 at 15:17 -0500, Seebs wrote:
On 1 Aug 2016, at 15:01, Richard Purdie wrote:

No, we're actually expecting it to retain the mode it was given via
the
hardlink under pseudo.

This is what a real world system would do and in this case we could
track it via pseudo since pseudo is loaded when the hardlink is
created. It would be unreasonable for pseudo to track all hardlinks
but
tracking ones created under it does seem reasonable?

Hmm. Well, strictly speaking, the link created under pseudo *does*
get
tracked. Hmm. But an implicit request to track also the thing linked
to
is not a horrible idea. Although you'd still be able to beat it:

        $ touch file1
        $ ln file1 file2
        $ pseudo
        # ln file2 file3
        # chmod 777 file3
        # rm file2 file3
        # ls -l file1

The general case of "find everything this link also refers to" is
clearly out of scope.

Agreed.

  That said... Hmm. I think my main feeling is, if we want
to link to the file, and we want the changes to the linked file to
survive, we should probably either create that file under pseudo, or
explicitly claim it with pseudo when we start wanting to do the
tracking.
(You can trivially do this to a tree with chown -R root tree).

The trouble is that for speed, we do create trees of hardlinked files
and play games with those and sstate amongst other things. Its
obviously faster to do this than make physical copies of the files.
Given what I know of the code paths, I suspect that tracking the source
of a hardlink would make life much easier for us. Obviously we can go
and start adding "chown -R" calls everywhere but that seems a little
ugly to me and doesn't do performance any favours.

Is there any significant downside if we do track the source of
hardlinks?

AFAIK, no.

And when remove file2, but file1's permission is changed, it should
be considered as a bug.

// Robert


Cheers,

Richard




--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to