[OE-core] About pseudo's chmod

[Seebs]

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.

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