Re: About pseudo's chmod

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

On 08/02/2016 02:30 PM, Seebs wrote:
> On 2 Aug 2016, at 1:07, Robert Yang wrote:
>
>> 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.
>
> Hmm. I'm a bit confused by this. Wouldn't the second build also do a
> "chmod 0444" on gzip-dbg/version.c? Why is it doing that chmod the first

Because the stat() gets 0644 on ${B}/version.c in the second run, so it
would run chmod 0644 rather than 0444 on gzip-dbg/version.c. And why it
gets 0644 ? pseudo's chmod automatically adds "w" on the real file, so:
if -e gzip-dbg/version.c; then
	${B}/version.c = 0444
else
	${B}/version.c = 0644
fi

And in the second run, gzip-dbg/version.c is removed and will be recreated,
so that it got 0644.

> time and not the second? If it does it the second time, the fact that
> the underlying file's mode changed won't matter.
>
> But in this case... While I'm fine with modifying things to track the

Thanks, I will send a patch for it.

> file linked-to, it still feels like this is a usage error. Fundamentally,
> we're unpacking a file (${B}/version.c), then linking to it, changing
> the link in some way, deleting the link, and expecting the original file
> to be unchanged. That doesn't seem right to me.

But that is what the real filesystem works without pseudo:
$ touch file1
$ ln file1 file2
$ chmod 777 file2
$ rm -f file2

file1 will be 777 on the real filesystem.

// Robert

>
> -s