Exact timestamp for sorting and renaming files according to creation order

[Polytropon]

On Wed, 04 Jan 2012 15:01:32 +0100, Julian H. Stacey wrote:
> Hi,
> Devin Teske wrote:
> > > -----Original Message-----
> > > From: owner-freebsd-questions at freebsd.org [mailto:owner-freebsd-
> > > questions at freebsd.org] On Behalf Of Polytropon
> > > Sent: Tuesday, January 03, 2012 1:00 PM
> > > To: Dan Nelson
> > > Cc: FreeBSD Questions
> > > Subject: Re: Exact timestamp for sorting and renaming files according to
> > creation
> > > order
> > > 
> > > On Tue, 3 Jan 2012 14:49:02 -0600, Dan Nelson wrote:
> > > > If you ask for the date to be printed in "float" (F) format, it gives
> > > > more precision.  The default is unsigned int (U) format.
> > > >
> > > > % stat -f "%N %FB" /COPYRIGHT
> > > > /COPYRIGHT 1306190895.046721049
> > > 
> > > Strangely, I only get a 000000000 "suffix" for any time stamp, no matter if I
> > create
> > > the file or apply the command as shown above to an existing file:
> > > 
> > > 	% stat -f "%N %FB" /COPYRIGHT
> > > 	/COPYRIGHT 1313951230.000000000
> > > 
> > > Am I missing some file system feature?
> > > 
> > > Otherwise, this _exactly_ looks like what I'm searching for. It doesn't need
> > to be
> > > a "human-readable" date representation.
> > > 
> > > by the way, I'm running FreeBSD 8.2-STABLE/x86 of late August 2011 here, file
> > > system used is UFS2.
> > 
> > On ZFS, all is well...
> > 
> > % df -hT /raid1/jails/package8-1/COPYRIGHT
> > Filesystem              Type    Size    Used   Avail Capacity  Mounted on
> > raid1/jails/package8-1  zfs     835G    672M    835G     0%
> > /raid1/jails/package8-1
> > 
> > % stat -f "%N %FB" /raid1/jails/package8-1/COPYRIGHT
> > /raid1/jails/package8-1/COPYRIGHT 1324356049.328275367
> > 
> > But alas, on UFS2:
> > 
> > % df -hT /COPYRIGHT
> > Filesystem     Type    Size    Used   Avail Capacity  Mounted on
> > /dev/mfid0s1a  ufs     989M     64M    846M     7%    /
> > 
> > % stat -f "%N %FB" /COPYRIGHT
> > /COPYRIGHT 1279505857.000000000

The idea of changing the sysctl vfs.timestamp_precision
to the value 3 worked on UFS for me. But it doesn't seem
to be the default.

Another problem might be when dealing with files that are
stored on a filesystem type different from UFS...



> I was wondering how df (& stat) could show more than seconds
> (Remembering back to 1990 & my
> 	http://berklix.com/~jhs/src/bsd/jhs/bin/public/statv/
> 	when Unix used unsigned long seconds since 1 jan 1970
> 	( & MSDOS was seconds divided by 2 since 1 jan 1980 )
> 	)
> FreeBSD 8.2-RELEASE /usr/src/usr.bin/stat/stat.c
> line 320 etc still uses the normal fstat stat lstat.
> But man 2 stat has extended :
>      #ifndef _POSIX_SOURCE
>      #define st_atime st_atimespec.tv_sec
>      #define st_mtime st_mtimespec.tv_sec
>      #define st_ctime st_ctimespec.tv_sec
>      #endif

The st_birthtime field would be the required one for
sorting here (and defaults, per definition, to seconds).
The "man 1 stat" mentions that stat uses the stat and
lstat system system calls, so this would be the value
that will be retrieved of no "finer time" can be
accessed (which would mean zeros here).



> cd /usr/include/sys ; vi -c/tv_sec /types.h stat.h
> #if __BSD_VISIBLE
> #define st_atime st_atimespec.tv_sec
> struct	timespec
> #include <sys/time.h>
> time.h:	#include <sys/timespec.h>
> timespec.h:
> struct timespec {time_t tv_sec;/* seconds */ long tv_nsec;/* nanoseconds */};
> 
> I guess extended timespec may get compiled in to VFS but not UFS,
> but no time to look further, Good luck Polytropn.

At least that's a starting point. I see that changing
the sysctl mentioned above seems to be sufficient for
the current purpose. However, I'd like to see the system
defaulting (!) to a resolution better than seconds, as
this is definitely possible.



> PS Here with UFS (per Dan's tip, thanks) I see:
> sysctl vfs.timestamp_precision=2 ; stat -f "%N %FB" /etc/motd
> 	/etc/motd 1306839862.000000000

That's understandable, as the "finer time" will
be generated only upon file _creation_; for files
that are already present, 000000000 is the typical
result.

	# sysctl vfs.timestamp_precision=3
	vfs.timestamp_precision: 0 -> 3

And then:

	% touch hickup.txt
	% stat -f "%N %FB" hickup.txt
	hickup.txt 1325686735.035925369

In comparison:

	% stat -f "%N %FB" /etc/motd
	/etc/motd 1309547364.000000000

which has been created prior to changing the
vfs.timestamp_precision sysctl.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...