On Mon, Oct 19, 2009 at 6:12 PM, Andreas Dilger <adilger@xxxxxxx> wrote: > On 19-Oct-09, at 16:24, Steve French wrote: >> some of the performance benefit - path based could be slightly >> slower (due to path revalidation, and access checks) than >> handle based calls. >> int (*setxattr) (struct dentry *, const char *,const void >> *,size_t,int); >> ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t); >> ssize_t (*listxattr) (struct dentry *, char *, size_t); >> int (*removexattr) (struct dentry *, const char *); > > I'm not sure I understand your point. sys_fgetxattr() maps directly to > vfs_getxattr(), and while it still does permission checks, that doesn't > have anything to do with pathname revalidation AFAICS. > > There are an equal number of permission checks in sys_fstat->vfs_getattr() > as in sys_fgetxattr->vfs_getxattr(). Good point. Looking more carefully I think you are right - the path revalidation is skipped in fgetxattr so it probably isn't much slower if at all (than a handle based ioctl call would be). >>> As for being able to write to the "create time" attribute, I would prefer >>> that this be a filesystem mount option. For some users (myself included) >>> I don't care whether Windows is unhappy that it can't update this >>> creation >>> time - I'd prefer to know when a file is actually created. > If this is a flag that a user can configure/select themselves, then it > is completely useless to me. If it is a mount option and/or possibly an > additional process capability that would be more useful. Yes ... there is a precedent for a process capability for something similar (e.g. a Windows user must have both the "backup privilege" in his process capability and specify a flag indicating he wants to use "backup intent" for certain operations). There are already 33 capabilities in include/linux/capability.h, some as narrow as this. -- Thanks, Steve -- 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
