Bug 3495 - Add support for real creation time on FreeBSD
Summary: Add support for real creation time on FreeBSD
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.21a
Hardware: All FreeBSD
: P3 enhancement
Target Milestone: none
Assignee: James Peach
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-09 17:18 UTC by Marcin Wisnicki
Modified: 2009-02-12 11:59 UTC (History)
2 users (show)

See Also:


Attachments
Sample patch (370 bytes, patch)
2006-02-09 17:19 UTC, Marcin Wisnicki
no flags Details
send birthtime (with configure checks) (1.11 KB, patch)
2006-07-10 16:06 UTC, Marcin Wisnicki
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Wisnicki 2006-02-09 17:18:27 UTC
FreeBSD 5+ with UFS2 provides real inode creation time in st_birthtime field of struct stat. If the filesystem doesn't support it, st_birthtime is set to -1.

Following sample patch adds support for st_birthtime to source/lib/time.c.

It should be made conditional on the presence of the field, unfortunately I'm not familiar with autotools. Any help on that will be appreciated.
Comment 1 Marcin Wisnicki 2006-02-09 17:19:37 UTC
Created attachment 1723 [details]
Sample patch
Comment 2 Jeremy Allison 2006-02-09 17:21:37 UTC
Great news ! I've been hoping a UNIX would provide this sometime. We need a configure.in test for the st_birthtime field of the stat struct though.
Jeremy.
Comment 3 Björn Jacke 2006-02-15 02:50:29 UTC
Solaris' ZFS also support creation times. A major task which still will have to be done for FreeBSD is *setting* the btime. There are two methods of setting creation time, if this is actually correct:

To provide a sensible birth time for applications that are unaware of the birth time attribute, we changed the semantics of the "utimes" system call so that if the birth time was newer than the value of the modification time that it was setting, it sets the birth time to the same time as the modification time. An application that is aware of the birth time attribute can set both the birth time and the modification time by doing two calls to "utimes". First it calls "utimes" with a modification time equal to the saved birth time, then it calls "utimes" a second time with a modification time equal to the (presumably newer) saved modification time. For filesystems that do not store birth times, the second call will overwrite the first call resulting in the same values for access and modification times as they would have previously gotten. For filesystems that support birth time, it will be properly set. And most happily for the application writers, they will not have to conditionally compile the name of "utimes" for BSD and non-BSD systems. They just write their applications to call the standard interface twice knowing that the right thing will happen on all systems and filesystems. For those applications that value speed of execution over portability can use the new version of the "utimes" system call that allows all time values to be set with one call. 
Comment 4 Marcin Wisnicki 2006-07-10 16:06:40 UTC
Created attachment 2027 [details]
send birthtime (with configure checks)

Add configure checks.

I've looked at adding ability to set birthtime but unfortunately there is still no "new" version of utimes syscall and with current utimes it would only be possible to set birthtime older than current.

Also there is no quick & easy way to implement it in samba ;(
What I gathered so far is that I would have to modify smbd/reply.c:reply_setattrE() and change file_utime()/SMB_VFS_UTIME (with modules) to use something more flexible than struct utimbuf that has only 2 fields: actime and modtime. Is that correct/all ?
Comment 5 James Peach 2007-05-14 22:54:49 UTC
I have equivalent patches for Darwin. I'll look at merging these and those.
Comment 6 Björn Jacke 2009-02-12 11:59:57 UTC
I Don't know if James merged his patches but the birthtime support (not setting however) is there now.