On Mon, 28 Sep 2020 22:42:18 +0100
"Richard Purdie" wrote:
> It helps to know that! I wasn't sure if you'd hate the path filtering.
It was on my to-do list at one point to be able to denote "the pseudo
filesystem" in some way and just politely ignore everything outside it.
And, possibly, switch
On Mon, 2020-09-28 at 10:56 -0500, Seebs wrote:
> On Mon, 28 Sep 2020 15:51:53 +0100
> "Richard Purdie" wrote:
>
> > I understand. I have strong evidence that the current handling of
> > such
> > a case does the wrong thing though as copying the data from the
> > original inode leads to pretty ba
On Mon, 28 Sep 2020 15:51:53 +0100
"Richard Purdie" wrote:
> I understand. I have strong evidence that the current handling of such
> a case does the wrong thing though as copying the data from the
> original inode leads to pretty bad corruption in its own right.
Yes.
But if you had to choose b
On Mon, 2020-09-28 at 09:13 -0500, Seebs wrote:
> On Mon, 28 Sep 2020 14:38:01 +0100
> "Richard Purdie" wrote:
>
> > This can happen when files are deleted outside of pseudo context
> > and
> > the inode is reused by a new file which pseduo then "sees".
>
> I'm just going to say again:
>
> The
On Mon, 28 Sep 2020 14:38:01 +0100
"Richard Purdie" wrote:
> This can happen when files are deleted outside of pseudo context and
> the inode is reused by a new file which pseduo then "sees".
I'm just going to say again:
The **ENTIRE REASON** pseudo exists to replace fakeroot is that
fakeroot d
Currently, where pseudo finds a database entry for an inode but the path
doesn't match, it reuses that database entry metadata. This is causing
real world "corruption" of file attributes.
See [YOCTO #14057] for an example of this.
This can happen when files are deleted outside of pseudo context a
