On Sun, 8 Aug 2010 05:12:09 -0700 Jeremy Allison <jra@xxxxxxxxx> wrote: > On Fri, Aug 06, 2010 at 01:38:36PM +1000, Neil Brown wrote: > > I'm curious. Why do you particularly care what interface the kernel uses to > > provide you with access to this attribute? > > It's a matter of taste. The *BSD's have this right IMHO. It > should be part of the stat information. A file timestamp is not > an EA. Making it available that way just feels like an appalingly > tasteless kludge. It offends the artist in me :-). > It would be more convenient if this were part of stat() but adding a new stat call is non-trivial. Even if we did that, it still doesn't solve the problem of being able to set the create time. The fact that that's rarely done doesn't really matter much -- we ought to shoot for the semantics that are needed to handle this properly. If we do settle on a xstat() interface, it might also end up being able to report things like selinux labels which are also available and settable via xattr. I don't see a problem with presenting the same data via multiple interfaces. If presenting this data via xattr solves the immediate problem of being able to properly store and report the create time then it seems like a win. > > Or do you really want something like BSD's 'btime' which as I understand it > > cannot be set. Would that be really useful to you? > > It is *already* useful to us, and is widely used in > existing code. The occasions when btime is set are > relatively rare, and at that point we store it in a > separate EA for Windows reporting purposes. > If that's the case, don't you have to query for this EA every time you need to return the create time anyway? If so, then doing this really isn't any more costly -- you'd just be querying a different EA, right? -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
