[OE-core] About pseudo's chmod

[Robert Yang]

Hi Peter,

Thanks for the reply.

On 07/30/2016 12:02 AM, Seebs wrote:
> On 29 Jul 2016, at 2:38, Robert Yang wrote:
>
>> It got 0644 but not 0444 in the second build was because pseudo's unlink
>> doesn't take core of hard links, for example:
>> $ umask 0022
>> $ touch file1
>> $ ln file1 file2
>> $ chmod 0777 file1
>> $ ls -l file1 file2
>> We can see that both file1 and file2's mode is 0777.
>
>> But if we remove file1:
>> $ rm -f file1
>> $ ls file2
>> Now file2's mode is 0644 since the info had been removed from database.
>
> I don't get that result. Before the remove, I see:
>
> sqlite> select * from files;
> 1|/home/seebs/pseudo/f1|2054|2757274|0|0|33279|0|0
> 2|/home/seebs/pseudo/f2|2054|2757274|0|0|33279|0|0
>
> So both files have the correct information stored for them. This is
> because chmod-type operations on files update everything with the same
> device and inode.

Sorry, the steps were wrong, they should be:
1) Out of pseudo:
    $ umask 0022
    $ touch file1
2) Under pseudo:
    $ ln file1 file2
    $ chmod 777 file2
    $ ls -l file1 file2
    We can see that both file1 and file2's mode is 0777.
    But if we remove file2:
    $ rm -f file2
    $ ls file1
    Now file1's permission is 0755, not 0777 or 0644, it should be 0777 here.

>
>> After talked with RP online, there isn't any file systems that can support
>> different modes on different references for the same inode, so pseudo's
>> chmod should update all the references' mode
>
> Yes.
>
>> in another word, it should
>> not remove the info from database if links count is greater than 1.
>
> This doesn't seem right to me. I can't produce any failures from the
> current code that match the behavior you're describing; updates like
> chmod always propogate to all the links.
>
> On the other hand, if f1 *already exists*, and was not being tracked
> by pseudo, then we do indeed see a similar problem. The underlying file's
> mode is actually changed.
>
> I do not think it would be a good idea at all to stop removing entries from the
> database when they become invalid. It seems to me that if we're hard linking to
> a file inside pseudo, we should probably be tracking that file. Although if we

Yes, I agree that we need track the src file when hard link.

// Robert

> track the file, now we'll just continue to see it as mode 777, because we
> changed the mode of the file.
>
> Consider, for a moment, what happens if you do this *without* pseudo involved.
> Unpack an archive containing a file "foo", mode 444.
>
> $ ln foo bar
> $ chmod 777 bar
> $ rm bar
> $ ls -l foo
>
> You'll find that foo's mode is now 0777. So it'd change either way; the
> difference is that, when pseudo's doing this, it masks out group and
> other write bits on the filesystem. (Because we don't want other people to be
> able to overwrite things in the build tree just because they'd be writeable on
> the target filesystem.)
>
> -s