file metadata via fs API (was: [GIT PULL] Filesystem Information)

[Andy Lutomirski]

> On Aug 11, 2020, at 8:20 AM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> 
> [ I missed the beginning of this discussion, so maybe this was already
> suggested ]
> 
>> On Tue, Aug 11, 2020 at 6:54 AM Miklos Szeredi <miklos at szeredi.hu> wrote:
>> 
>>> 
>>> E.g.
>>>  openat(AT_FDCWD, "foo/bar//mnt/info", O_RDONLY | O_ALT);
>> 
>> Proof of concept patch and test program below.
> 
> I don't think this works for the reasons Al says, but a slight
> modification might.
> 
> IOW, if you do something more along the lines of
> 
>       fd = open(""foo/bar", O_PATH);
>       metadatafd = openat(fd, "metadataname", O_ALT);
> 
> it might be workable.
> 
> So you couldn't do it with _one_ pathname, because that is always
> fundamentally going to hit pathname lookup rules.
> 
> But if you start a new path lookup with new rules, that's fine.
> 
> This is what I think xattrs should always have done, because they are
> broken garbage.
> 
> In fact, if we do it right, I think we could have "getxattr()" be 100%
> equivalent to (modulo all the error handling that this doesn't do, of
> course):
> 
>  ssize_t getxattr(const char *path, const char *name,
>                        void *value, size_t size)
>  {
>     int fd, attrfd;
> 
>     fd = open(path, O_PATH);
>     attrfd = openat(fd, name, O_ALT);
>     close(fd);
>     read(attrfd, value, size);
>     close(attrfd);
>  }
> 
> and you'd still use getxattr() and friends as a shorthand (and for
> POSIX compatibility), but internally in the kernel we'd have a
> interface around that "xattrs are just file handles" model.
> 
> 

This is a lot like a less nutty version of NTFS streams, whereas the /// idea is kind of like an extra-nutty version of NTFS streams.

I am personally not a fan of the in-band signaling implications of overloading /.  For example, there is plenty of code out there that thinks that (a + “/“ + b) concatenates paths. With /// overloaded, this stops being true.