[OE-core] About pseudo's chmod

[Seebs]

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.

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