Messages in this thread | | | From | Linus Torvalds <> | Date | Tue, 11 Aug 2020 08:20:24 -0700 | Subject | Re: file metadata via fs API (was: [GIT PULL] Filesystem Information) |
| |
[ 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@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.
Linus
| |