Re: file forks vs. xattr (was: xattr names for unprivileged stacking?)

Miklos Szeredi
2020-08-24T20:01:59Z

On Mon, Aug 24, 2020 at 5:30 PM Christian Schoenebeck
<qemu_oss@crudebyte.com> wrote:
>

> Hu, you're right! There is indeed a somewhat congruent effort & discussion
> going on in parallel. Pulling in Miklos into CC for that reason:
> https://lore.kernel.org/lkml/CAJfpegtNP8rQSS4Z14Ja4x-TOnejdhDRTsmmDD-Cccy2pkfVVw@mail.gmail.com/
>
> However the motivation of that other thread's PR was rather a procfs-like
> system as a unified way to retrieve implementation specific info from an
> underlying fs, and the file fork aspect would just be a 'side product'.

The motivation is a consistent interface for accessing file related
data, whatever that be.

> But as they already pointed out, it would be a problem to actually agree about
> a delimiter between the filename and the fork name portion. Miklos suggested a
> a double/triple slash, but I agree with other ones that this would render
> misbehaviours with all sorts of existing applications:
> https://lore.kernel.org/lkml/c013f32e-3931-f832-5857-2537a0b3d634@schaufler-ca.com/

That argument starts like this:

- Path resolution has allowed multiple slashes in UNIX systems for 50
years, so everyone got used to building paths by concatenating things
ending in slashes and beginning in slashes and putting more slashes in
the middle.

This can't be argued with, we probably have to live with that for 50
more years (if we are lucky).

The argument continues so:

- Because everyone got lazy, we can't introduce a new interface with
new rules, because all those lazy programmers won't be bothered to fix
their ways and will use the old practices while trying to use the new
interface, which will break their new apps.

Huh? Can't they just fix those broken apps, then?

Yeah, yeah, I know it's not as simple as that, as the path can come
from application A, while the new interface is used by application B.
But this would only be a real backward compatibility issue if the new
interface is used without consideration for such cases (i.e. clean up
paths coming from untrusted sources before using it with the new
interface).

So no, I don't buy that argument. Anyway, starting with just path
resolution starting at the target file makes sense as a first step.

The most important thing, I think, is to not fragment the interface
further. So O_ALT should allow not just one application (like ADS)
but should have a top level directory for selecting between the
various data sources.

Thanks,
Miklos