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 exp
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 file
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 th
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 w
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 v
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 th
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 Sze
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 s
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 s
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 understand
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 question
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 and
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 /pro
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 moun
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 sp
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 b
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 corres
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 ope
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.
But
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 fstatf
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 m
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
> serv
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 to
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?
> Beca
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 u
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 walk
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
sna
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.:
m
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 notification
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 desig
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 ov
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
> eff
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 h
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 s
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. You'r
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 shoul
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 their
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 w
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 users
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 softw
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 bor
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 t
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
> > compatibility
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 v
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, sin
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 you
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 s
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", O
> 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);
> >
> > Pr
[ 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 t
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 pathna
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, Miklo
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 Mikl
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 xat
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 fits
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 pur
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 purpose char in filenames, and even repetitions
> are allowed, it's hard to t
80 matches
Mail list logo
