[OE-core] About pseudo's chmod

Robert Yang liezhi.yang at windriver.com
Tue Aug 2 08:32:06 UTC 2016



On 08/02/2016 02:50 PM, Seebs wrote:
> On 2 Aug 2016, at 1:44, Robert Yang wrote:
>
>> 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.
>
> Why is it calling chmod at all? The goal is apparently to give
> gzip-dbg/version.c the same mode that ${B}/version.c has. Since it's a
> hard link, no chmod call is needed at all.

It is worth trying, I will try to remove os.chown() and os.chmod() from
package.bbclass to see what will happen:

             if not cpath.islink(file):
                 os.link(file, fpath)
                 fstat = cpath.stat(file)
                 os.chmod(fpath, fstat.st_mode)
                 os.chown(fpath, fstat.st_uid, fstat.st_gid)

>
>>> 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.
>
> I already have a patch for this.
>
>>> 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.
>
> Yes. But it seems that the mode the file is being changed to is dependant on the
> original reported mode. And that's the part that I'm confused by;
> we're relying on the mode of the original file, but we're also changing
> the mode of a hard link to it. This makes no sense to me.
>
> So, I have a likely fix handy. (The difference between mine and the
> version you proposed earlier is that, as I recall, yours does the LINK
> operation on the original file unconditionally, which is in error; it

I had checked pseudo's source code, I didn't find any function that can check
this, and I appreciated that if you can fix it:-).

// Robert

> should only be done when no existing data was found in the database.) I'll
> double-check that again and go through looking for loose ends, because
> I have a vague feeling that I'm overlooking a thing, but I haven't figured out
> what it would be yet.
>
> -s



More information about the Openembedded-core mailing list