Re: About pseudo's chmod

[Robert Yang <liezhi.yang@windriver.com>]

On 08/02/2016 02:07 PM, Robert Yang wrote:
>
>
> On 08/02/2016 11:43 AM, Seebs wrote:
>> On 1 Aug 2016, at 20:52, Robert Yang wrote:
>>
>>> And when remove file2, but file1's permission is changed, it should
>>> be considered as a bug.
>>
>> I'm not sure of that. My interpretation would be that hard linking under pseudo
>> to files which weren't created under the same pseudo database is
>> user error; that's not how the database is intended to work. That said, it's
>> pretty trivial to add the things to it.
>>
>> Although I'd like to know more about the use cases for these, because it
>> occurs to me that the qualifier "same pseudo database" points out another
>
> Currently, the problem in oe-core is:
>
>        1) bitbake gzip
>        2) Edit rpm-native or package.bbclass to make do_package re-run.
>        3) bitbake gzip
>        After the first build, build/version.c in gzip-dbg is 0444, but after
>        the second build, it will be 0644, this is because do_package does:
>        $ ln ${B}/version.c gzip-dbg/version.c,
>        $ chmod 0444 gzip-dbg/version.c (it runs chmod 0644 on the real filesystem)
>        And in the second build, the gzip-dbg/version.c will be removed and
>        created again, so that stat() can't get 0444 but 0644 since
>        ${B}/version.c is not tracked by pseudo.


And please see the first email in the thread for more details.

// Robert

>
> // Robert
>
>> possible failure mode: Would any of those files that are being linked to
>> be getting linked to from *more than one* pseudo database? Because if they were,
>> that would be a thing I haven't been planning for and I don't know
>> whether it'd work sanely.
>>
>> -s