i've got nas running zfs , i'd preserve creation times when transferring files it. both linux/ext4 (where data now) , zfs store creation time or birth time. in case of zfs it's reported stat command. haven't been able figure out how can set creation time of file mirrors creation time in original file system. unlike ext4->ext4 transfer can feed debugfs script set file creation times.
is there tool similar debugfs zfs?
ps. explain better:
i have usb drive attached ubuntu 14.04 laptop. holds file system care creation date (birth date) of individual files. consult these creation timestamps using script based on debugfs, reports crtime.
i want move data nas box running zfs, methods know (scp -p -r, rsync -a, , tar, among others i've tried) preserve modification time not creation time.
if moving ext4 file system solve problem using fantastic tool
debugfs. can make list of (filename, crtime) pairs on source fs (file system), usedebugfs -won target fs read script lines of formset_inode_field filename crtime <value>
i've tested , works fine.
but target fs not ext4 zfs , although
debugfsruns on target machine, entirely useless there. doesn't recognize fs. debug tool lets alter timestamps editing inode directly fsdb; runs on target machine, again can't seem recognize zfs file system.i'm told folks sold me nas box debugfs , fsdb not meant zfs filesystems, haven't been able come equivalent. so, after googling , trying out things decided post question here today, hoping might have answer.
i'm surprised @ how hard turning out be. question of how replicate dataset timestamps identical seems quite natural archival point of view.
indeed, neither fsdb nor debugfs suitable use zfs. might need instead find archive format preserve crtime field presumably set files on fileserver. if there version of pax or archiving tool system may able (cf. -pe "preserve everything" flag pax seems in current versions not preserve "everything" - viz. not preserve crtime/birth_time). have more success finding archiving application "crtime aware" trying set creation times hacking on zfs based freebsd system rudimentary tools.
you may able find more advanced tools on opensolaris based systems illumos or smartos (e.g. mdb). whether possible transfer data zfs dataset on 1 of platforms , then, combining tools have with, say, dtrace in order rewrite crtime fields more of theoretical question. if worked export pool , datasets freebsd - exporting pool seem preserve crtime time stamps. if are able preserve crtime while dumping ext4 filesystem zfsonlinux dataset on same host (nb: have not tested this) use zfs send transfer whole filesystem nas.
this core utils bug report may shed light on state of user , operating system level tools on linux. arguably filesystem level crtime field of inode should difficult change. while zfs on freebsd "supports" crtime, state of low level filesystem debugging tools on freebsd might not have kept pace in earlier releases (c.f. zdb manual page). sure want "set" (or reset) inode creation times? or want preserve them after have been set on system supports them?
on freebsd system if stat file stored on zfs dataset notice crtime field of file set same time ctime field. because application wrote file did not have access library , kernel functions required set crtime @ time file "born" , inode entries created. there examples of applications / libraries try preserve crtime @ application level such libarchive(3) (see also: archive_entry_atime(3)) , gracefully handle inode creation if archive restored on filesystem not support crtime field. might not relevant in case.
as might imagine, there lot of applications write files filesystems ... unix/posix systems "everything file". i'm not sure if older applications need modified or recompiled support fields, or whether pick them transparently host system's c libraries. applications being used on older freebsd releases or on linux system without ext4 made run in compatibility mode on date os, example, whether handle time fields question.
for me running little script sh birthtime_test confirms file creation times "turned on" on freebsd systems (all of use zfs post v28 i.e. feature flags):
#!/bin/sh #birthtime_test uname -r if [ -f new_born ] ; rm -f new_born ; fi touch new_born sleep 3 touch -a new_born sleep 3 echo "hello new_born at:" >> new_born echo `date` >> new_born sleep 3 chmod o+w new_born stat -f "name:%t%n born:%t%sb access:%t%sa modify:%t%sm change:%t%sc" new_born cat new_born output:
9.2-release-p10 name: new_born born: may 7 12:38:35 2015 access: may 7 12:38:38 2015 modify: may 7 12:38:41 2015 change: may 7 12:38:44 2015 hello new_born at: thu may 7 12:38:41 edt 2015 (nb: chmod operation "changes" not "modify" file contents - echo command adding content file. see touch manual page explanations of -m , -a flags).
this oldest freebsd release have access right now. i'd curious know how far in release cycle freebsd able handle (on zfs or ufs2 file systems). i'm pretty sure has been feature quite while now. there osx , linux versions of zfs useful know regarding feature.
just 1 more thing ...
here nice feature simple "forensics". want send our new_born file when time began, leap second never happened , when - in moment of timeless time - unix born ... :-) 1. can change date using touch -d , think new_born old , wise, right?
nope:
~/ % touch -d "1970-01-01t00:00:01" new_born ~/ % stat -f "name:%t%n born:%t%sb access:%t%sa modify:%t%sm change:%t%sc" new_born name: new_born born: may 7 12:38:35 2015 access: jan 1 00:00:01 1970 modify: jan 1 00:00:01 1970 change: may 7 13:29:37 2015 it's more truthful be young :-)
time , unix - subject both practical , poetic: after all, "change"; , mean "modify" or "create" something? great post silvio - hope lives on , gathers useful answers.
you can improve , generalize question if can more specific requirements preserving, setting, archiving of file timestamp fields. don't me wrong: question , continue votes long time.
you might take @ dylan leigh's presentation forensic timestamp analysis of zfs or contact dylan clues on how access crftime information.
[1] there legend claimed in beginning, seconds since long (ssl) ago never less date -u -j -f "%y-%m-%d:%t" "1970-01-01:00:00:01" "+%s" because of leap second ...
