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

Andreas Dilger adilger at sun.com
Tue Oct 20 18:44:08 MDT 2009

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  
One issue that I've already come across is if we are storing a raw  
we will get different xattrs on disk in the fallback case where the on- 
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  
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  
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>

More information about the samba-technical mailing list