Re: O_NONBLOCK for regular files
On Wed, 2005-04-13 at 15:56, Trond Myklebust wrote: on den 13.04.2005 Klokka 10:45 (+1000) skreiv Greg Banks: There's now a patch to actually do it, see http://marc.theaimsgroup.com/?l=linux-nfsm=111087383132762w=2 Does anyone want to give a firm yea or nea to this approach? I'd really like to get this patch moving in the pipeline. Nay... if (rqstp-rq_vers == 3) is BAD! We're already busy with rq_vers == 4 (which has the same issues). This sort of condition needs to be handled in a more version-independent manner. Yes, Neil already made this point. I have a new version of the patch which does if (rqstp-rq_vers = 3) which I'll resend if there are no other issues. I assume that'll be good enough. Any other issues? Greg. -- Greg Banks, RD Software Engineer, SGI Australian Software Group. I don't speak for SGI. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Wed, Apr 13, 2005 at 11:14:10 +0200, Miklos Szeredi wrote: There are uses for both. For example today I was updating the tar ball which is used to create the var file system for a new chroot. I certainly want to see corretly setup owner/permissions when I look into that tar ball using a FUSE fs... If I'm updating a var filesystem for a new chroot, I'd need the ability to chmod and chown things in that filesystem. Does that work as an ordinary user? Yes, within UML for example. That's a bad example. UML does in fact *NOT* invoke host kernel's chmod, because it has all the filesystem in a file. But the answer is yes anyway. It's up to the filesystem to check whether it is allowed. FUSE does not block it and if the actual userland driver does not protest either, it is possible. [...] --- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Aren't there some assumptions in VFS that currently make this impossible? I believe it's OK with VFS, but applications would be confused to death. Well, there really is one issue -- dentries have exactly one parent, so what do you do when opening a file with hardlinks as a directory? (In fact IIRC that is what lead to all the funny talk about mountpoints, since they don't have this limitation) OK, that makes sense. It would be quite interesting to see how applications react. Maybe I'll hack something up :) Thanks, Miklos - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Look up the rather large linux-kernel linux-fsdevel thread silent semantic changes with reiser4 and it's followup threads, from last year. Wow, it's 700+ messages. I got through the first 40, and already feel dizzy :) It's already been tried. You will also find sensible ideas on what semantics it should have to do it properly. OK, I understand the slash - directory, no-slash - regular file semantics. How do you envision implementing this for mount directory over file? A new mount flag indicating that it's only to be followed down if there's a slash after the mountpoint? Thanks, Miklos - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: Look up the rather large linux-kernel linux-fsdevel thread silent semantic changes with reiser4 and it's followup threads, from last year. Wow, it's 700+ messages. I got through the first 40, and already feel dizzy :) It's easier if you skip the ones by Hans and their immediate followups :) (Nothing personal, it's that Hans is mostly justifying reiser4's behaviour, and the posts you really need to read aren't about reiser4). It's already been tried. You will also find sensible ideas on what semantics it should have to do it properly. OK, I understand the slash - directory, no-slash - regular file semantics. How do you envision implementing this for mount directory over file? Somewhere deep in that thread is a discussion between Al Viro and Linus on it. A new mount flag indicating that it's only to be followed down if there's a slash after the mountpoint? The new flag would indicate more than that: These mounts should be detachable in the sense that deleting the file is possible, and perhaps renamable/linkable too. That's the stuff Al Viro discusses in some detail in the big thread. Ideally we'd like automounting, a bit like the Hurd's translators. Attached to files (using an xattr or something, and executed with the uid/gid of the file owner), and also per-user pattern-action options for matching files with a certain type (e.g. tgz/zip/deb/rpm/xml). But that can be added much later, as it's an orthogonal feature. -- Jamie - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: Yet, the results from stat() don't distinguish the number spaces, and ls doesn't map the numbers to names properly in the wrong space. Well you can use ls -n. It's up to the tools to present the information you want in the way you want it. If a tool can't do that, tough, but you are not worse off than if the information is not available _at_all_. Well, how do you currently provide access to the information that's not presentable through stat()? -- Jamie - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Yet, the results from stat() don't distinguish the number spaces, and ls doesn't map the numbers to names properly in the wrong space. Well you can use ls -n. It's up to the tools to present the information you want in the way you want it. If a tool can't do that, tough, but you are not worse off than if the information is not available _at_all_. Well, how do you currently provide access to the information that's not presentable through stat()? Obviously I don't. However that's hardly an argument for providing even less information. And stat() btw pretty much covers what information there is to present for network filesystems and archives, since there _is_ a real filesystem where the information originated from (though sometimes it's not a UNIX type of filesystem, in which case there has to be some mapping of the info). Miklos - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [autofs] Re: [ANNOUNCE] Important update - autofs 4.1.4 release
== Regarding [autofs] Re: [ANNOUNCE] Important update - autofs 4.1.4 release;
[EMAIL PROTECTED] adds:
raven On Sun, 10 Apr 2005 [EMAIL PROTECTED] wrote:
Hi all,
Here is autofs 4.1.4.
raven There were a couple of mistakes in the release.
raven The kernel patches have been updated as there were some obvious
raven errors in them. An error in patching of the Debian portion of the
raven init script was corrected.
raven I've uploaded corrected versions along with a MD5SUMS file of
raven checksums for people to verify against.
raven The new upload has a timestamp of 11-Apr-2005 06:21-59. If you
raven downloaded anything before this, sorry, you'll need to get the
raven updated files.
This new version has regressed since beta2 for /net mounts in my
environment. A simple ls of /net/filer will now show the contents of
/net/filer/exporteddir. So, for example, we have devfiler which exports
/vol/vol1. When I do an ls of /net/devfiler, I get the contents of
devfiler:/vol/vol1.
Okay, after further debugging, it seems we're not identifying this as a
multimount entry. It's getting late, so I'm going to turn this over to
you. I think that the checking of first_chunk is bogus. For instance,
with the below change, everything works as expected for me.
-Jeff
--- autofs-4.1.4/modules/parse_sun.c.orig 2005-04-13 21:52:21.663629568
-0400
+++ autofs-4.1.4/modules/parse_sun.c2005-04-13 21:52:31.687105768 -0400
@@ -766,7 +766,7 @@ static int check_is_multi(const char *ma
{
const char *p = (char *) mapent;
int multi = 0;
- int first_chunk = 0;
+ int first_chunk = 1;
while (*p) {
p = skipspace(p);
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
