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

Mingming cmm at us.ibm.com
Mon Oct 19 18:41:03 MDT 2009


On Mon, 2009-10-19 at 12:55 -0600, Andreas Dilger wrote:
> On 19-Oct-09, at 11:17, Steve French wrote:
> > A new version of the format for Samba server related file system
> > extended attributes is expected in the next version of Samba so the
> > topic of create time and nanosecond timestamps for Linux has come up
> > again.  Since some file systems don't support storing create time
> > (birth time), and none support updating create time, or for that
> > matter for storing any nanosecond timestamps at all (a millisecond
> > seems like a much longer time today than when the stat structure was
> > defined), and dos attributes, Samba server stores these in extended
> > attributes, which is awkward on those file systems which store
> > (different) versions of these on disk.
> 
> 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).
> 
> I believe that nanosecond timestamps ARE supported with newer  
> filesystems
> using stat().  There is the utimensat() system call, which takes a  
> timespec
> parameter, so it looks to be suitable for setting nanosecond timestamps
> from userspace.  I don't know if glibc() supports this, but I do see it
> in the kernel.
> 

How we are going to set the nanotimestamps today? utimes(2) man page
seems indicating it only support setting time at  microseond level.

> As for _updating_ create time, isn't that sort of defeating the purpose
> of create time?
> 

Perphas the backup/restore wants to preserve the original creation
timestamp after the file being backuped?

> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html




More information about the samba-technical mailing list