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

[Andreas Dilger]

On 20-Oct-09, at 14:49, Steve French wrote:
> On Tue, Oct 20, 2009 at 3:33 PM, Andreas Dilger <adilger at sun.com>  
> wrote:
>> For those users/admins that want to be able to change this (due to
>> Samba, or whatever), great, we can give them this ability, but for
>> users who do NOT want regular users to be able to change the file
>> creation timestamp, that should be possible as well.
>
> So, are we ready for Mingming or one of the ext4 developers to propose
> a patch for this via xattrs (I can do a similar one for cifs).
> Sounds like various have said:
>
> 1) xattrs instead of ioctl
> 2) get of create time allowed by default, but set of create time  
> limited


A wildly untested/uncompiled patch is attached for purposes of  
discussion.
One issue that I've already come across is if we are storing a raw  
"timespec"
we will get different xattrs on disk in the fallback case where the on- 
disk
inodes are not large enough to store the crtime inside the inode.

This version of the patch will fall back to storing the timespec on disk
in the supplied size/endianness as an xattr, but it definitely needs  
to be
handled more appropriately (endian/word size).  It _would_ be nice to  
store
a full 64-bit timespec on disk, but given that the in-inode format  
only can
handle 34 bits of seconds + 30 bits of nanoseconds, it isn't clear  
whether
the "fallback" should do better than that.

The main question is whether storing a "user.crtime" as an on-disk xattr
is a desirable fallback, or if this should just fail?  Similarly, should
the lack of on-disk crtime return "0.0" as the creation time, or should
it return -ENODATA or similar?

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crtime_xattr.diff
Type: application/octet-stream
Size: 3308 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20091020/5aee3860/attachment.obj>