Re: file metadata via fs API (was: [GIT PULL] Filesystem Information)
From: Miklos Szeredi <miklos@szeredi.hu>
Date: 2020-08-12 14:46:35
Also in:
linux-fsdevel, linux-security-module, lkml
From: Miklos Szeredi <miklos@szeredi.hu>
Date: 2020-08-12 14:46:35
Also in:
linux-fsdevel, linux-security-module, lkml
On Wed, Aug 12, 2020 at 4:40 PM Al Viro [off-list ref] wrote:
On Wed, Aug 12, 2020 at 09:23:23AM +0200, Miklos Szeredi wrote:quoted
Anyway, starting with just introducing the alt namespace without unification seems to be a good first step. If that turns out to be workable, we can revisit unification later.Start with coming up with answers to the questions on semantics upthread. To spare you the joy of digging through the branches of that thread, how's that for starters? "Can those suckers be passed to ...at() as starting points?
No.
Can they be bound in namespace?
No.
Can something be bound *on* them?
No.
What do they have for inodes and what maintains their inumbers (and st_dev, while we are at it)?
Irrelevant. Can be some anon dev + shared inode. The only attribute of an attribute that I can think of that makes sense would be st_size, but even that is probably unimportant.
Can _they_ have secondaries like that (sensu Swift)?
Reference?
Is that a flat space, or can they be directories?"
Yes it has a directory tree. But you can't mkdir, rename, link, symlink, etc on anything in there. Thanks, Miklos