[OE-core] About pseudo's chmod

[Robert Yang]

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
>
>
>
>