ext4 - getting at birth time (file create time) and getting/setting nanosecond time stamps and utime

[Steve French]

On Mon, Oct 19, 2009 at 3:11 PM, Andreas Dilger <adilger at sun.com> wrote:
> On 19-Oct-09, at 13:45, Steve French wrote:
>>
>> On Mon, Oct 19, 2009 at 1:55 PM, Andreas Dilger <adilger at sun.com> wrote:
>>>
>>> I had proposed in the past that these file attributes be exposed to
>>> userspace as virtual xattrs, e.g. user.cr_time returning a struct
>>> timespec, but the data is stored internal to the filesystem in whatever
>>> format is most efficient for it.  We only strictly need user.crtime
>>> for this, but I wouldn't object to exporting other inode attributes in
>>> this way (e.g. user.mtime, user.atime, etc).
>>
>> Yes - the fake xattr approach was the approach that I preferred
>> (since I could do this trivially to cifs, and for ext4 it seems equally
>> easy),
>> but I wonder if this "path based" approach is slightly harder for Samba,
>> since for most cases Samba maps to "handle based" equivalents
>> (when the same operation can come in eitherpath based or
>> handle based - Samba mostly maps to handle based).
>
> Could you please elaborate what you mean by "path based" for xattrs?
> They can be gotten with sys_fgetxattr() from a file handle just as
> easily as from the filename.

Although handle based interfaces are there for xattrs in userspace,
internally the xattr calls are path based, so handle based
calls get converted to path based in kernel and you could lose
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 definitely agree with having a common attribute name for these.
>
> 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.

I agree - if create time could be overwritten - that behavior hould be
configurable (another post mentioned the alternative to mount
option - a flag for this perhaps along the lines of the a "backup intent"
flag - although somewhat different than what Windows uses that for).



-- 
Thanks,

Steve