From: Miklos Szeredi <miklos@szeredi.hu> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>, David Howells <dhowells@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, Karel Zak <kzak@redhat.com>, Jeff Layton <jlayton@redhat.com>, Miklos Szeredi <mszeredi@redhat.com>, Nicolas Dichtel <nicolas.dichtel@6wind.com>, Christian Brauner <christian@brauner.io>, Lennart Poettering <lennart@poettering.net>, Linux API <linux-api@vger.kernel.org>, Ian Kent <raven@themaw.net>, LSM <linux-security-module@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: file metadata via fs API (was: [GIT PULL] Filesystem Information) Date: Tue, 11 Aug 2020 20:49:35 +0200 [thread overview] Message-ID: <CAJfpeguo5nAWcmduX4frknQGiRJeaj9Rdj018xUBrwqOJhVufw@mail.gmail.com> (raw) In-Reply-To: <CAHk-=wg_bfVf5eazwH2uXTG-auCYZUpq-xb1kDeNjY7yaXS7bw@mail.gmail.com> On Tue, Aug 11, 2020 at 6:05 PM Linus Torvalds <torvalds@linux-foundation.org> 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, since that should work most of the time even in those concatenated cases. And yes, I know, most is not always, and this might just be hiding bugs, etc... I think the pragmatic approach would be to try this and see how many triple slash hits a normal workload gets and if it's reasonably low, then hopefully that together with warnings for O_ALT would be enough. > (b) even if the new user space were to think about that, and remove > those (hah! when have you ever seen user space do that?), as Al > mentioned, the user *filesystem* might have pathnames with double > slashes as part of symlinks. > > So now we'd have to make sure that when we traverse symlinks, that > O_ALT gets cleared. That's exactly what I implemented in the proof of concept patch. > Which means that it's not a unified namespace > after all, because you can't make symlinks point to metadata. I don't think that's a great deal. Also I think other limitations would make sense: - no mounts allowed under /// - no ./.. resolution after /// - no hardlinks - no special files, just regular and directory - no seeking (regular or dir) > cat my-file.tar/inside/the/archive.c > > or similar. > > Al has convinced me it's a horrible idea (and there you have a > non-ambiguous marker: the slash at the end of a pathname that > otherwise looks and acts as a non-directory) Umm, can you remind me what's so horrible about that? Yeah, hard linked directories are a no-no. But it doesn't have to be implemented in a way to actually be a problem with hard links. Thanks, Miklos
next prev parent reply other threads:[~2020-08-11 18:49 UTC|newest] Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-03 15:27 [GIT PULL] Mount notifications David Howells 2020-08-03 15:49 ` [GIT PULL] Filesystem Information David Howells 2020-08-03 16:42 ` Miklos Szeredi 2020-08-04 2:15 ` Ian Kent 2020-08-04 14:36 ` Miklos Szeredi 2020-08-05 1:33 ` Ian Kent 2020-08-05 8:00 ` Miklos Szeredi 2020-08-05 11:13 ` Ian Kent 2020-08-05 8:24 ` file metadata via fs API (was: [GIT PULL] Filesystem Information) Miklos Szeredi 2020-08-11 13:54 ` Miklos Szeredi 2020-08-11 14:08 ` Al Viro 2020-08-11 14:22 ` Miklos Szeredi 2020-08-11 14:31 ` Al Viro [not found] ` <CAAgocE07=vVKpQhG+rjEGO=NEBKZ02gjg4TRPxECAc+RKrzn=Q@mail.gmail.com> 2020-08-11 14:36 ` Al Viro 2020-08-11 14:36 ` Miklos Szeredi 2020-08-11 14:42 ` Al Viro 2020-08-11 14:47 ` Miklos Szeredi 2020-08-11 15:20 ` Linus Torvalds 2020-08-11 15:30 ` Miklos Szeredi 2020-08-11 16:05 ` Linus Torvalds 2020-08-11 18:49 ` Miklos Szeredi [this message] 2020-08-11 19:31 ` Lennart Poettering 2020-08-11 19:50 ` Christian Brauner 2020-08-11 19:39 ` Christian Brauner 2020-08-12 0:53 ` Ian Kent 2020-08-11 15:39 ` Andy Lutomirski 2020-08-11 16:17 ` Casey Schaufler 2020-08-11 16:30 ` Linus Torvalds 2020-08-11 20:28 ` Miklos Szeredi 2020-08-11 20:36 ` Jann Horn 2020-08-11 20:56 ` Miklos Szeredi 2020-08-11 21:17 ` Andy Lutomirski 2020-08-11 21:18 ` Linus Torvalds 2020-08-12 7:23 ` Miklos Szeredi 2020-08-12 14:39 ` Al Viro 2020-08-12 14:46 ` Miklos Szeredi 2020-08-12 15:08 ` Al Viro 2020-08-12 15:13 ` Miklos Szeredi 2020-08-12 16:33 ` Al Viro 2020-08-12 17:16 ` Miklos Szeredi 2020-08-12 17:39 ` Al Viro 2020-08-12 18:33 ` Al Viro 2020-08-12 21:30 ` Al Viro 2020-08-18 9:41 ` Miklos Szeredi 2020-08-18 9:30 ` Miklos Szeredi 2020-08-12 15:22 ` David Howells 2020-08-11 21:20 ` Al Viro 2020-08-11 21:35 ` Casey Schaufler 2020-08-11 16:05 ` Al Viro 2020-08-11 16:09 ` Linus Torvalds 2020-08-11 16:39 ` Al Viro 2020-08-12 10:14 ` Karel Zak 2020-08-12 13:09 ` Miklos Szeredi 2020-08-12 13:33 ` David Howells 2020-08-12 13:54 ` Miklos Szeredi 2020-08-12 0:05 ` David Howells 2020-08-12 7:55 ` Miklos Szeredi 2020-08-12 8:29 ` David Howells 2020-08-12 8:37 ` Miklos Szeredi 2020-08-12 9:43 ` file metadata via fs API Steven Whitehouse 2020-08-12 10:04 ` Miklos Szeredi 2020-08-12 11:28 ` Karel Zak 2020-08-12 12:43 ` Miklos Szeredi 2020-08-13 8:52 ` Karel Zak 2020-08-12 13:06 ` David Howells 2020-08-13 1:01 ` Ian Kent 2020-08-12 18:18 ` file metadata via fs API (was: [GIT PULL] Filesystem Information) Linus Torvalds 2020-08-12 19:34 ` file metadata via fs API Steven Whitehouse 2020-08-12 19:50 ` Linus Torvalds 2020-08-13 3:44 ` Ian Kent 2020-08-13 10:36 ` Karel Zak 2020-08-14 7:58 ` Lennart Poettering 2020-08-17 11:32 ` Steven Whitehouse 2020-08-17 17:15 ` Linus Torvalds 2020-08-17 22:44 ` Linus Torvalds 2020-08-18 12:50 ` Miklos Szeredi 2020-08-18 18:51 ` Linus Torvalds 2020-08-18 20:18 ` Miklos Szeredi 2020-08-18 20:53 ` Linus Torvalds 2020-08-21 13:17 ` Miklos Szeredi 2020-08-19 2:29 ` Al Viro 2020-08-13 3:53 ` file metadata via fs API (was: [GIT PULL] Filesystem Information) Jeffrey E Altman 2020-08-14 17:05 ` Linus Torvalds 2020-08-18 15:01 ` Jeffrey E Altman 2020-08-14 8:06 ` Lennart Poettering 2020-08-12 13:54 ` David Howells 2020-08-12 14:10 ` Miklos Szeredi 2020-08-12 14:23 ` David Howells 2020-08-03 22:48 ` [GIT PULL] Mount notifications Ian Kent
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAJfpeguo5nAWcmduX4frknQGiRJeaj9Rdj018xUBrwqOJhVufw@mail.gmail.com \ --to=miklos@szeredi.hu \ --cc=christian@brauner.io \ --cc=dhowells@redhat.com \ --cc=jlayton@redhat.com \ --cc=kzak@redhat.com \ --cc=lennart@poettering.net \ --cc=linux-api@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=mszeredi@redhat.com \ --cc=nicolas.dichtel@6wind.com \ --cc=raven@themaw.net \ --cc=torvalds@linux-foundation.org \ --cc=viro@zeniv.linux.org.uk \ --subject='Re: file metadata via fs API (was: [GIT PULL] Filesystem Information)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).