On Tue, Aug 18, 2020 at 10:53 PM Linus Torvalds
wrote:
> Basically, I think a rough rule of thumb can and should be:
>
> - stuff that the VFS knows about natively and fully is clearly pretty
> mount-agnostic and generic, and can be represented in whatever
> extended "struct statfs_x" directly.
On Tue, Aug 18, 2020 at 11:51:25AM -0700, Linus Torvalds wrote:
> I think people who have problems parsing plain ASCII text are just
> wrong. It's not that expensive. The thing that makes /proc/mounts
> expensive is not the individual lines - it's that there are a lot of
> them.
It is
On Tue, Aug 18, 2020 at 1:18 PM Miklos Szeredi wrote:
>
> So why mix a binary structure into it? Would it not make more sense
> to make it text only?
.. because for basic and standard stuff, the binary structure just
makes sense and is easier for everybody.
When I want to get the size of a
On Tue, Aug 18, 2020 at 8:51 PM Linus Torvalds
wrote:
> I think people who have problems parsing plain ASCII text are just
> wrong. It's not that expensive. The thing that makes /proc/mounts
> expensive is not the individual lines - it's that there are a lot of
> them.
I agree completely with
On Tue, Aug 18, 2020 at 5:50 AM Miklos Szeredi wrote:
>
> How do you propose handling variable size attributes, like the list of
> fs options?
I really REALLY think those things should just be ASCII data.
I think marshalling binary data is actively evil and wrong. It's great
for well-specified
On 8/14/2020 1:05 PM, Linus Torvalds (torva...@linux-foundation.org) wrote:
> Honestly, I really think you may want an extended [f]statfs(), not
> some mount tracking.
>
> Linus
Linus,
Thank you for the reply. Perhaps some of the communication disconnect
is due to which thread
On Tue, Aug 18, 2020 at 12:44 AM Linus Torvalds
wrote:
> So please. Can we just make a simple extended statfs() and be done
> with it, instead of this hugely complex thing that does five different
> things with the same interface and makes it really odd as a result?
How do you propose handling
On Wed, Aug 12, 2020 at 11:30 PM Al Viro wrote:
>
> On Wed, Aug 12, 2020 at 07:33:26PM +0100, Al Viro wrote:
>
> > BTW, what would such opened files look like from /proc/*/fd/* POV? And
> > what would happen if you walk _through_ that symlink, with e.g. ".."
> > following it? Or with names of
On Wed, Aug 12, 2020 at 8:33 PM Al Viro wrote:
>
> On Wed, Aug 12, 2020 at 06:39:11PM +0100, Al Viro wrote:
> > On Wed, Aug 12, 2020 at 07:16:37PM +0200, Miklos Szeredi wrote:
> > > On Wed, Aug 12, 2020 at 6:33 PM Al Viro wrote:
> > > >
> > > > On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos
On Mon, Aug 17, 2020 at 10:15 AM Linus Torvalds
wrote:
>
> So it has this very complex "random structures of random things"
> implementation. It's a huge sign of over-design and "I don't know what
> the hell I want to expose, so I'll make this generic thing that can
> expose anything, and then I
On Mon, Aug 17, 2020 at 4:33 AM Steven Whitehouse wrote:
>
> That said, the overall aim here is to solve the problem and if there are
> better solutions available then I'm sure that everyone is very open to
> those. I agree very much that monitoring at kHz frequencies is not
> useful, but at the
Hi,
On 12/08/2020 20:50, Linus Torvalds wrote:
On Wed, Aug 12, 2020 at 12:34 PM Steven Whitehouse wrote:
The point of this is to give us the ability to monitor mounts from
userspace.
We haven't had that before, I don't see why it's suddenly such a big deal.
The notification side I
On Wed, Aug 12, 2020 at 8:53 PM Jeffrey E Altman wrote:
>
> For the AFS community, fsinfo offers a method of exposing some server
> and volume properties that are obtained via "path ioctls" in OpenAFS and
> AuriStorFS. Some example of properties that might be exposed include
> answers to
On Mi, 12.08.20 11:18, Linus Torvalds (torva...@linux-foundation.org) wrote:
> On Tue, Aug 11, 2020 at 5:05 PM David Howells wrote:
> >
> > Well, the start of it was my proposal of an fsinfo() system call.
>
> Ugh. Ok, it's that thing.
>
> This all seems *WAY* over-designed - both your fsinfo
On Mi, 12.08.20 12:50, Linus Torvalds (torva...@linux-foundation.org) wrote:
> On Wed, Aug 12, 2020 at 12:34 PM Steven Whitehouse
> wrote:
> >
> > The point of this is to give us the ability to monitor mounts from
> > userspace.
>
> We haven't had that before, I don't see why it's suddenly such
On Wed, Aug 12, 2020 at 12:50:28PM -0700, Linus Torvalds wrote:
> Convince me otherwise. AGAIN. This is the exact same issue I had with
> the notification queues that I really wanted actual use-cases for, and
> feedback from actual outside users.
I thought (in last 10 years) we all agree that
On Wed, Aug 12, 2020 at 02:43:32PM +0200, Miklos Szeredi wrote:
> On Wed, Aug 12, 2020 at 1:28 PM Karel Zak wrote:
>
> > The proposal is based on paths and open(), how do you plan to deal
> > with mount IDs? David's fsinfo() allows to ask for mount info by mount
> > ID and it works well with
On 8/12/2020 2:18 PM, Linus Torvalds (torva...@linux-foundation.org) wrote:
> What's wrong with fstatfs()? All the extra magic metadata seems to not
> really be anything people really care about.
>
> What people are actually asking for seems to be some unique mount ID,
> and we have 16 bytes of
On Wed, 2020-08-12 at 12:50 -0700, Linus Torvalds wrote:
> On Wed, Aug 12, 2020 at 12:34 PM Steven Whitehouse <
> swhit...@redhat.com> wrote:
> > The point of this is to give us the ability to monitor mounts from
> > userspace.
>
> We haven't had that before, I don't see why it's suddenly such a
On Wed, 2020-08-12 at 14:06 +0100, David Howells wrote:
> Miklos Szeredi wrote:
>
> > That presumably means the mount ID <-> mount path mapping already
> > exists, which means it's just possible to use the open(mount_path,
> > O_PATH) to obtain the base fd.
>
> No, you can't. A path more
On Wed, Aug 12, 2020 at 07:33:26PM +0100, Al Viro wrote:
> BTW, what would such opened files look like from /proc/*/fd/* POV? And
> what would happen if you walk _through_ that symlink, with e.g. ".."
> following it? Or with names of those attributes, for that matter...
> What about a normal
On Wed, Aug 12, 2020 at 12:34 PM Steven Whitehouse wrote:
>
> The point of this is to give us the ability to monitor mounts from
> userspace.
We haven't had that before, I don't see why it's suddenly such a big deal.
The notification side I understand. Polling /proc files is not the answer.
Hi,
On 12/08/2020 19:18, Linus Torvalds wrote:
On Tue, Aug 11, 2020 at 5:05 PM David Howells wrote:
Well, the start of it was my proposal of an fsinfo() system call.
Ugh. Ok, it's that thing.
This all seems *WAY* over-designed - both your fsinfo and Miklos' version.
What's wrong with
On Wed, Aug 12, 2020 at 06:39:11PM +0100, Al Viro wrote:
> On Wed, Aug 12, 2020 at 07:16:37PM +0200, Miklos Szeredi wrote:
> > On Wed, Aug 12, 2020 at 6:33 PM Al Viro wrote:
> > >
> > > On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos Szeredi wrote:
> >
> > > > Why does it have to have a struct
On Tue, Aug 11, 2020 at 5:05 PM David Howells wrote:
>
> Well, the start of it was my proposal of an fsinfo() system call.
Ugh. Ok, it's that thing.
This all seems *WAY* over-designed - both your fsinfo and Miklos' version.
What's wrong with fstatfs()? All the extra magic metadata seems to not
On Wed, Aug 12, 2020 at 07:16:37PM +0200, Miklos Szeredi wrote:
> On Wed, Aug 12, 2020 at 6:33 PM Al Viro wrote:
> >
> > On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos Szeredi wrote:
>
> > > Why does it have to have a struct mount? It does not have to use
> > > dentry/mount based path lookup.
On Wed, Aug 12, 2020 at 6:33 PM Al Viro wrote:
>
> On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos Szeredi wrote:
> > Why does it have to have a struct mount? It does not have to use
> > dentry/mount based path lookup.
>
> What the fuck? So we suddenly get an additional class of objects
>
On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos Szeredi wrote:
> > Lovely. And what of fchdir() to those?
>
> Not allowed.
Not allowed _how_? Existing check is "is it a directory"; what do you
propose? IIRC, you've mentioned using readdir() in that context, so
it's not that you only allow
Miklos Szeredi wrote:
> Why does it have to have a struct mount? It does not have to use
> dentry/mount based path lookup.
file->f_path.mnt
David
On Wed, Aug 12, 2020 at 5:08 PM Al Viro wrote:
>
> On Wed, Aug 12, 2020 at 04:46:20PM +0200, Miklos Szeredi wrote:
>
> > > "Can those suckers be passed to
> > > ...at() as starting points?
> >
> > No.
>
> Lovely. And what of fchdir() to those?
Not allowed.
> Are they all non-directories?
>
On Wed, Aug 12, 2020 at 04:46:20PM +0200, Miklos Szeredi wrote:
> > "Can those suckers be passed to
> > ...at() as starting points?
>
> No.
Lovely. And what of fchdir() to those? Are they all non-directories?
Because the starting point of ...at() can be simulated that way...
> > Can they be
On Wed, Aug 12, 2020 at 4:40 PM Al Viro wrote:
>
> On Wed, Aug 12, 2020 at 09:23:23AM +0200, Miklos Szeredi wrote:
>
> > 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
On Wed, Aug 12, 2020 at 09:23:23AM +0200, Miklos Szeredi wrote:
> 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
Miklos Szeredi wrote:
> The point is that generic operations already exist and no need to add
> new, specialized ones to access metadata.
open and read already exist, yes, but the metadata isn't currently in
convenient inodes and dentries that you can just walk through. So you're
going to end
On Wed, Aug 12, 2020 at 3:54 PM David Howells wrote:
>
> Linus Torvalds wrote:
>
> > 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.
>
> What is it going to
On Wed, Aug 12, 2020 at 3:33 PM David Howells wrote:
>
> Miklos Szeredi wrote:
>
> > You said yourself, that what's really needed is e.g. consistent
> > snapshot of a complete mount tree topology. And to get the complete
> > topology FSINFO_ATTR_MOUNT_TOPOLOGY and FSINFO_ATTR_MOUNT_CHILDREN are
Linus Torvalds wrote:
> 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.
What is it going to walk through? You need to end up with an inode and dentry
from somewhere.
Miklos Szeredi wrote:
> You said yourself, that what's really needed is e.g. consistent
> snapshot of a complete mount tree topology. And to get the complete
> topology FSINFO_ATTR_MOUNT_TOPOLOGY and FSINFO_ATTR_MOUNT_CHILDREN are
> needed for *each* individual mount.
That's not entirely true.
On Wed, Aug 12, 2020 at 12:14 PM Karel Zak wrote:
> For example, by fsinfo(FSINFO_ATTR_MOUNT_TOPOLOGY) you get all
> mountpoint propagation setting and relations by one syscall,
That's just an arbitrary grouping of attributes.
You said yourself, that what's really needed is e.g. consistent
Miklos Szeredi wrote:
> That presumably means the mount ID <-> mount path mapping already
> exists, which means it's just possible to use the open(mount_path,
> O_PATH) to obtain the base fd.
No, you can't. A path more correspond to multiple mounts stacked on top of
each other, e.g.:
On Wed, Aug 12, 2020 at 1:28 PM Karel Zak wrote:
> The proposal is based on paths and open(), how do you plan to deal
> with mount IDs? David's fsinfo() allows to ask for mount info by mount
> ID and it works well with mount notification where you get the ID. The
> collaboration with
On Wed, Aug 12, 2020 at 12:04:14PM +0200, Miklos Szeredi wrote:
> On Wed, Aug 12, 2020 at 11:43 AM Steven Whitehouse
> wrote:
> >
> > Hi,
> >
> > On 12/08/2020 09:37, Miklos Szeredi wrote:
> > [snip]
> > >
> > > b) The awarded performance boost is not warranted for the use cases it
> > > is
On Tue, Aug 11, 2020 at 08:20:24AM -0700, Linus Torvalds wrote:
> 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.
I have thought we want to replace mountinfo to reduce
On Wed, Aug 12, 2020 at 11:43 AM Steven Whitehouse wrote:
>
> Hi,
>
> On 12/08/2020 09:37, Miklos Szeredi wrote:
> [snip]
> >
> > b) The awarded performance boost is not warranted for the use cases it
> > is designed for.
>
> This is a key point. One of the main drivers for this work is the
>
Hi,
On 12/08/2020 09:37, Miklos Szeredi wrote:
[snip]
b) The awarded performance boost is not warranted for the use cases it
is designed for.
Thanks,
Miklos
This is a key point. One of the main drivers for this work is the
efficiency improvement for large numbers of mounts. Ian and Karel
On Wed, Aug 12, 2020 at 10:29 AM David Howells wrote:
>
> Miklos Szeredi wrote:
>
> > Worried about performance? Io-uring will allow you to do all those
> > five syscalls (or many more) with just one I/O submission.
>
> io_uring isn't going to help here. We're talking about synchronous reads.
Miklos Szeredi wrote:
> Worried about performance? Io-uring will allow you to do all those
> five syscalls (or many more) with just one I/O submission.
io_uring isn't going to help here. We're talking about synchronous reads.
AIUI, you're adding a couple more syscalls to the list and running
On Wed, Aug 12, 2020 at 2:05 AM David Howells wrote:
> > {
> > int fd, attrfd;
> >
> > fd = open(path, O_PATH);
> > attrfd = openat(fd, name, O_ALT);
> > close(fd);
> > read(attrfd, value, size);
> > close(attrfd);
> > }
>
> Please don't go down this path.
On Tue, Aug 11, 2020 at 11:19 PM Linus Torvalds
wrote:
>
> On Tue, Aug 11, 2020 at 1:56 PM Miklos Szeredi wrote:
> >
> > So that's where O_ALT comes in. If the application is consenting,
> > then that should prevent exploits. Or?
>
> If the application is consenting AND GETS IT RIGHT it
On Tue, 2020-08-11 at 21:39 +0200, Christian Brauner wrote:
> On Tue, Aug 11, 2020 at 09:05:22AM -0700, Linus Torvalds wrote:
> > On Tue, Aug 11, 2020 at 8:30 AM Miklos Szeredi
> > wrote:
> > > What's the disadvantage of doing it with a single lookup WITH an
> > > enabling flag?
> > >
> > > It's
Linus Torvalds wrote:
> [ I missed the beginning of this discussion, so maybe this was already
> suggested ]
Well, the start of it was my proposal of an fsinfo() system call. That at its
simplest takes an object reference (eg. a path) and an integer attribute ID (it
could use a string instead,
On 8/11/2020 1:28 PM, Miklos Szeredi wrote:
> On Tue, Aug 11, 2020 at 6:17 PM Casey Schaufler
> wrote:
>
>> Since ab has known meaning, and lots of applications
>> play loose with '/', its really dangerous to treat the string as
>> special. We only get away with '.' and '..' because
On Tue, Aug 11, 2020 at 10:28:31PM +0200, Miklos Szeredi wrote:
> On Tue, Aug 11, 2020 at 6:17 PM Casey Schaufler
> wrote:
>
> > Since ab has known meaning, and lots of applications
> > play loose with '/', its really dangerous to treat the string as
> > special. We only get away with
On Tue, Aug 11, 2020 at 1:56 PM Miklos Szeredi wrote:
>
> So that's where O_ALT comes in. If the application is consenting,
> then that should prevent exploits. Or?
If the application is consenting AND GETS IT RIGHT it should prevent exploits.
But that's a big deal.
Why not just do it the
On Tue, Aug 11, 2020 at 1:56 PM Miklos Szeredi wrote:
>
> On Tue, Aug 11, 2020 at 10:37 PM Jann Horn wrote:
> > If you change the semantics of path strings, you'd have to be
> > confident that the new semantics fit nicely with all the path
> > validation routines that exist scattered across
On Tue, Aug 11, 2020 at 10:37 PM Jann Horn wrote:
> If you change the semantics of path strings, you'd have to be
> confident that the new semantics fit nicely with all the path
> validation routines that exist scattered across userspace, and don't
> expose new interfaces through file server
On Tue, Aug 11, 2020 at 10:29 PM Miklos Szeredi wrote:
> On Tue, Aug 11, 2020 at 6:17 PM Casey Schaufler
> wrote:
> > Since ab has known meaning, and lots of applications
> > play loose with '/', its really dangerous to treat the string as
> > special. We only get away with '.' and '..'
On Tue, Aug 11, 2020 at 6:17 PM Casey Schaufler wrote:
> Since ab has known meaning, and lots of applications
> play loose with '/', its really dangerous to treat the string as
> special. We only get away with '.' and '..' because their behavior
> was defined before many of y'all were
On Tue, Aug 11, 2020 at 09:31:05PM +0200, Lennart Poettering wrote:
> On Di, 11.08.20 20:49, Miklos Szeredi (mik...@szeredi.hu) wrote:
>
> > On Tue, Aug 11, 2020 at 6:05 PM Linus Torvalds
> > wrote:
> >
> > > and then people do "$(srctree)/". If you haven't seen that kind of
> > > pattern where
On Tue, Aug 11, 2020 at 09:05:22AM -0700, Linus Torvalds wrote:
> On Tue, Aug 11, 2020 at 8:30 AM Miklos Szeredi wrote:
> >
> > What's the disadvantage of doing it with a single lookup WITH an enabling
> > flag?
> >
> > It's definitely not going to break anything, so no backward
> >
On Di, 11.08.20 20:49, Miklos Szeredi (mik...@szeredi.hu) wrote:
> On Tue, Aug 11, 2020 at 6:05 PM Linus Torvalds
> wrote:
>
> > and then people do "$(srctree)/". If you haven't seen that kind of
> > pattern where the pathname has two (or sometimes more!) slashes in the
> > middle, you've led a
On Tue, Aug 11, 2020 at 6:05 PM Linus Torvalds
wrote:
> and then people do "$(srctree)/". If you haven't seen that kind of
> pattern where the pathname has two (or sometimes more!) slashes in the
> middle, you've led a very sheltered life.
Oh, I have. That's why I opted for triple slashes,
On Tue, Aug 11, 2020 at 09:09:36AM -0700, Linus Torvalds wrote:
> On Tue, Aug 11, 2020 at 9:05 AM Al Viro wrote:
> >
> > Except that you suddenly see non-directory dentries get children.
> > And a lot of dcache-related logics needs to be changed if that
> > becomes possible.
>
> Yeah, I think
On Tue, Aug 11, 2020 at 9:17 AM Casey Schaufler wrote:
>
> This doesn't work so well for setxattr(), which we want to be atomic.
Well, it's not like the old interfaces could go away. But yes, doing
metadatafd = openat(fd, "metadataname", O_ALT | O_CREAT | O_EXCL)
to create a new xattr
On 8/11/2020 8:39 AM, Andy Lutomirski wrote:
>
>> On Aug 11, 2020, at 8:20 AM, Linus Torvalds
>> 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 wrote:
>>>
E.g.
openat(AT_FDCWD,
On Tue, Aug 11, 2020 at 9:05 AM Al Viro wrote:
>
> Except that you suddenly see non-directory dentries get children.
> And a lot of dcache-related logics needs to be changed if that
> becomes possible.
Yeah, I think you'd basically need to associate a (dynamic)
mount-point to that path when you
On Tue, Aug 11, 2020 at 8:30 AM Miklos Szeredi wrote:
>
> What's the disadvantage of doing it with a single lookup WITH an enabling
> flag?
>
> It's definitely not going to break anything, so no backward
> compatibility issues whatsoever.
No backwards compatibility issues for existing programs,
On Tue, Aug 11, 2020 at 08:20:24AM -0700, Linus Torvalds wrote:
> 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",
> On Aug 11, 2020, at 8:20 AM, Linus Torvalds
> 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 wrote:
>>
>>>
>>> E.g.
>>> openat(AT_FDCWD, "foo/bar//mnt/info", O_RDONLY | O_ALT);
>>
>>
On Tue, Aug 11, 2020 at 5:20 PM Linus Torvalds
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 wrote:
> >
> > >
> > > E.g.
> > > openat(AT_FDCWD, "foo/bar//mnt/info", O_RDONLY | O_ALT);
> >
> >
[ I missed the beginning of this discussion, so maybe this was already
suggested ]
On Tue, Aug 11, 2020 at 6:54 AM Miklos Szeredi 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
On Tue, Aug 11, 2020 at 4:42 PM Al Viro wrote:
>
> On Tue, Aug 11, 2020 at 04:36:32PM +0200, Miklos Szeredi wrote:
>
> > > > - strip off trailing part after first instance of ///
> > > > - perform path lookup as normal
> > > > - resolve meta path after /// on result of normal lookup
> > >
> >
On Tue, Aug 11, 2020 at 04:36:32PM +0200, Miklos Szeredi wrote:
> > > - strip off trailing part after first instance of ///
> > > - perform path lookup as normal
> > > - resolve meta path after /// on result of normal lookup
> >
> > ... and interpolation of relative symlink body into the
On Tue, Aug 11, 2020 at 4:31 PM Al Viro wrote:
>
> On Tue, Aug 11, 2020 at 04:22:19PM +0200, Miklos Szeredi wrote:
> > On Tue, Aug 11, 2020 at 4:08 PM Al Viro wrote:
> > >
> > > On Tue, Aug 11, 2020 at 03:54:19PM +0200, Miklos Szeredi wrote:
> > > > On Wed, Aug 05, 2020 at 10:24:23AM +0200,
On Tue, Aug 11, 2020 at 10:33:59AM -0400, Tang Jiye wrote:
> anyone knows how to post a question?
Generally the way you just have, except that you generally
put it *after* the relevant parts of the quoted text (and
removes the irrelevant ones).
On Tue, Aug 11, 2020 at 04:22:19PM +0200, Miklos Szeredi wrote:
> On Tue, Aug 11, 2020 at 4:08 PM Al Viro wrote:
> >
> > On Tue, Aug 11, 2020 at 03:54:19PM +0200, Miklos Szeredi wrote:
> > > On Wed, Aug 05, 2020 at 10:24:23AM +0200, Miklos Szeredi wrote:
> > > > On Tue, Aug 4, 2020 at 4:36 PM
On Tue, Aug 11, 2020 at 4:08 PM Al Viro wrote:
>
> On Tue, Aug 11, 2020 at 03:54:19PM +0200, Miklos Szeredi wrote:
> > On Wed, Aug 05, 2020 at 10:24:23AM +0200, Miklos Szeredi wrote:
> > > On Tue, Aug 4, 2020 at 4:36 PM Miklos Szeredi wrote:
> > >
> > > > I think we already lost that with the
On Tue, Aug 11, 2020 at 03:54:19PM +0200, Miklos Szeredi wrote:
> On Wed, Aug 05, 2020 at 10:24:23AM +0200, Miklos Szeredi wrote:
> > On Tue, Aug 4, 2020 at 4:36 PM Miklos Szeredi wrote:
> >
> > > I think we already lost that with the xattr API, that should have been
> > > done in a way that
On Wed, Aug 05, 2020 at 10:24:23AM +0200, Miklos Szeredi wrote:
> On Tue, Aug 4, 2020 at 4:36 PM Miklos Szeredi wrote:
>
> > I think we already lost that with the xattr API, that should have been
> > done in a way that fits this philosophy. But given that we have "/"
> > as the only special
79 matches
Mail list logo
