On Sonntag, 30. August 2020 21:05:40 CEST Miklos Szeredi wrote:
> On Sat, Aug 29, 2020 at 9:25 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> > On Sat, Aug 29, 2020 at 09:13:24PM +0200, Miklos Szeredi wrote:
> > > > d_path() is the least of the problems, actually. Directory tree
> > > > structure on those, OTOH, is a serious problem. If you want to have
> > > > getdents(2) on that shite, you want an opened descriptor that looks
> > > > like a directory. And _that_ opens a large can of worms. Because
> > > > now you have fchdir(2) to cope with, lookups going through
> > > > /proc/self/fd/<n>/..., etc., etc.
> > >
> > > Seriously, nobody wants fchdir(). And getdents() does not imply
> > > fchdir().
> >
> > Yes, it does. If it's a directory, fchdir(2) gets to deal with it.
> > If it's not, no getdents(2). Unless you special-case the damn thing in
> > said fchdir(2).
>
> Huh? f_op->iterate() needed for getdents(2) and i_op->lookup() needed
> for fchdir(2).
>
> Yes, open(..., O_ALT) would be special. Let's call it open_alt(2) to
> avoid confusion with normal open on a normal filesystem. No special
> casing anywhere at all. It's a completely new interface that returns
> a file which either has ->read/write() or ->iterate() and which points
> to an inode with empty i_ops.
Wouldn't that be overkill to introduce a new syscall just for that?
My {disclaimer: quick & naive} approach would be sticking a new flag
S_ALT_WHATEVER onto i_flags maybe? And hard code denial in
inode_permission(MAY_EXEC) if that S_ALT_WHATEVER flag is present? Then you
can getdents() but not fchdir() into it, if I am not missing something.
On Montag, 31. August 2020 09:34:20 CEST Miklos Szeredi wrote:
> On Sun, Aug 30, 2020 at 9:10 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
> > On Sun, Aug 30, 2020 at 09:05:40PM +0200, Miklos Szeredi wrote:
> > > Yes, open(..., O_ALT) would be special. Let's call it open_alt(2) to
> > > avoid confusion with normal open on a normal filesystem. No special
> > > casing anywhere at all. It's a completely new interface that returns
> > > a file which either has ->read/write() or ->iterate() and which points
> > > to an inode with empty i_ops.
> >
> > I think fiemap() should be allowed on a stream. After all, these extents
> > do exist. But I'm opposed to allowing getdents(); it'll only encourage
> > people to think they can have non-files as streams.
>
> Call it whatever you want. I think getdents (without lseek!!!) is a
> fine interface for enumeration.
>
> Also let me stress again, that this ALT thing is not just about
> streams, but a generic interface for getting OOB/meta/whatever data
> for a given inode/path. Hence it must have a depth of at least 2, but
> limiting it to 2 would again be shortsighted.
Al, feeling about these two issues?
On Montag, 31. August 2020 16:23:12 CEST Theodore Y. Ts'o wrote:
> On Sat, Aug 29, 2020 at 09:12:45PM +0100, Matthew Wilcox wrote:
> > > 3) what happens to it if that underlying file is unlinked?
> >
> > Unlinking a file necessarily unlinks all the streams. So the file
> > remains in existance until all fds on it are closed, including all
> > the streams.
>
> That's a bad idea, because if the fds are closed silently, then they
> can be reused; and then if the userspace library tries to write to
> what it *thinks* is an ADS file, not knowing that the application has
> unlinked and closed the ADS file, user file data would be lost.
Why would that be bad with ADS while it is Ok with regular files right now?
Best regards,
Christian Schoenebeck
