On Mon, Aug 31, 2020 at 3:23 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Mon, Aug 31, 2020 at 01:51:20PM +0200, Miklos Szeredi wrote: > > On Mon, Aug 31, 2020 at 1:37 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > > As I said to Dave, you and I have a strong difference of opinion here. > > > I think that what you are proposing is madness. You're making it too > > > flexible which comes with too much opportunity for abuse. > > > > Such as? > > One proposal I saw earlier in this thread was to do something like > $ runalt /path/to/file ls > which would open_alt() /path/to/file, fchdir to it and run ls inside it. > That's just crazy. Indeed, I have said numerous times that fchdir() on those objects must not happen. But there's no law (that I know of) that says all hierarchies of files must allow fchdir(). > > > I just want > > > to see alternate data streams for the same filename in order to support > > > existing use cases. You seem to be able to want to create an entire > > > new world inside a file, and that's just too confusing. > > > > To whom? I'm sure users of ancient systems with a flat directory > > found directory trees very confusing. Yet it turned out that the > > hierarchical system beat the heck out of the flat one. > > Which doesn't mean that multiple semi-hidden hierarchies are going to > be better than one visible hierarchy. Look how metadata interfaces for inodes are already fragmented: - stat (zillions of versions due to field sizes) - statx (hopefully good for some time) - getxattr - FS_IOC_GETFLAGS - FS_IOC_FSGETXATTR (nothing to do with the "other" xattr) - FS_IOC_FIEMAP - all the filesystem specific stuff (encryption, compression, whatever) And now you are proposing to add yet another interface specific to ADS. What about a generic interface instead for most future use cases as well as possibly duplicating some of the existing ones? This would simplify userspace tooling and allow for a single generic internal interface as well. Thanks, Miklos
