On Thu, Mar 25, 2010 at 04:27:13PM +0200, Boaz Harrosh wrote: > And about the NFS thing, let misbehaving applications byte there own bullets. > But a good app like git, does put an O_DIRECTORY on the directory open, and > therefore will receive consistent results, right? What the hell do you mean, "misbehaving"? O_DIRECTORY means one thing: "refuse to open if it turns out to be a non-directory". If open() succeed with it and fails without, it's a definite bug. Application has every right to call the damn thing without that flag. It *can* be used as a hint by fs code, and it's a useful hint, so yes, we need to restore LOOKUP_DIRECTORY (until we get rid of the entire d_revalidate/lookup+open mess and pass struct file + open flags directly to fs method for the last step of pathname resolution; basically, most of the do_last() guts would become that method, killing the intents crap for good; new method would simply check for O_DIRECTORY presence instead of looking at LOOKUP_DIRECTORY). However, NFS behaviour in cases when O_DIRECTORY is absent is a separate (and quite real) bug. If nfs_atomic_lookup() sees -EISDIR from attempt to open on server, it should either issue plain lookup or try to use the information it got in response to open attempt (if there's enough of it there). Passing -EISDIR to ->lookup() caller is simply wrong. I'm going to send a fix for O_DIRECTORY case (restoring the behaviour we had in 2.6.33) today, but NFS side of things also needs to be dealt with. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
