file-ctime and file-mtime giving wrong value

[Derick Eddington]

[d@eep:/tmp]-> touch f
[d@eep:/tmp]-> stat f
  File: `f'
  Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 807h/2055d Inode: 11110 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ d) Gid: ( 1000/ d)
Access: 2008-11-11 13:06:35.000000000 -0800
Modify: 2008-11-11 13:06:35.000000000 -0800
Change: 2008-11-11 13:06:35.000000000 -0800
[d@eep:/tmp]-> ./s f
st_ctime = 1226437595 st_mtime = 1226437595
[d@eep:/tmp]->

Ikarus Scheme version 0.0.3+ (revision 1668, build 2008-11-11)
Copyright (c) 2006-2008 Abdulaziz Ghuloum

> (printf "~x\n" 1226437595)
4919F3DB
> #x919F3DB ;; fix(0x4919F3DB)
152695771
> (file-ctime "/tmp/f")
152695771000000000
>

Also, is there some POSIX facility to get finer-than-second resolution of files' ctime and mtime that file-ctime and file-mtime are being left open to supporting in the future, and that's why these values are multiplied by #e1e9?

[Abdulaziz Ghuloum (aghuloum)]

On Nov 11, 2008, at 4:22 PM, Derick Eddington wrote:

> Also, is there some POSIX facility to get finer-than-second resolution
> of files' ctime and mtime that file-ctime and file-mtime are being
> left
> open to supporting in the future, and that's why these values are
> multiplied by #e1e9?

What do I know! Looks like there is a nanosecond field for stat.

In /usr/include/sys/stat.h under Darwin:

struct stat {
         dev_t st_dev; /* [XSI] ID of device
containing file */
         ino_t st_ino; /* [XSI] File serial number */
         mode_t st_mode; /* [XSI] Mode of file (see
below) */
         nlink_t st_nlink; /* [XSI] Number of hard
links */
         uid_t st_uid; /* [XSI] User ID of the file */
         gid_t st_gid; /* [XSI] Group ID of the
file */
         dev_t st_rdev; /* [XSI] Device ID */
#ifndef _POSIX_C_SOURCE
         struct timespec st_atimespec; /* time of last access */
         struct timespec st_mtimespec; /* time of last data
modification */
         struct timespec st_ctimespec; /* time of last status
change */
#else
         time_t st_atime; /* [XSI] Time of last access */
         long st_atimensec; /* nsec of last access */
         time_t st_mtime; /* [XSI] Last data
modification time */
         long st_mtimensec; /* last data modification
nsec */
         time_t st_ctime; /* [XSI] Time of last status
change */
         long st_ctimensec; /* nsec of last status
change */
#endif
         off_t st_size; /* [XSI] file size, in bytes */
         blkcnt_t st_blocks; /* [XSI] blocks allocated
for file */
         blksize_t st_blksize; /* [XSI] optimal blocksize
for I/O */
         __uint32_t st_flags; /* user defined flags for
file */
         __uint32_t st_gen; /* file generation number */
         __int32_t st_lspare; /* RESERVED: DO NOT USE! */
         __int64_t st_qspare[2]; /* RESERVED: DO NOT USE! */
};

[Abdulaziz Ghuloum (aghuloum)]

On Nov 11, 2008, at 4:22 PM, Derick Eddington wrote:

>> (printf "~x\n" 1226437595)
> 4919F3DB
>> #x919F3DB ;; fix(0x4919F3DB)
> 152695771
>> (file-ctime "/tmp/f")
> 152695771000000000

These are wrapping around because the correct value is
outside of the fixnum range. So, fix(---) is chopping
the high bits incorrectly. Will fix.

[Derick Eddington (derick-eddington)]

On Tue, 2008-11-11 at 21:56 +0000, Abdulaziz Ghuloum wrote:
> On Nov 11, 2008, at 4:22 PM, Derick Eddington wrote:
>
> > Also, is there some POSIX facility to get finer-than-second resolution
> > of files' ctime and mtime that file-ctime and file-mtime are being
> > left
> > open to supporting in the future, and that's why these values are
> > multiplied by #e1e9?
>
> What do I know! Looks like there is a nanosecond field for stat.
>
> In /usr/include/sys/stat.h under Darwin:

Ah, cool. Also just discovered the same under Linux (manpage for stat):

NOTES
   Linux Notes
       Since kernel 2.5.48, the stat structure supports nanosecond resolution for the
       three file timestamp fields. Glibc exposes the nanosecond component of each
       field using names either of the form st_atim.tv_nsec, if the _BSD_SOURCE or
       _SVID_SOURCE feature test macro is defined, or of the form st_atimensec, if nei‐
       ther of these macros is defined. On file systems that do not support sub-second
       timestamps, these nanosecond fields are returned with the value 0.

I was using the POSIX docs earlier, and these fields aren't in POSIX
(though it seems to leave it open so the standard fields could be any
resolution), but I bet it'd be relatively easy to #ifdef them portably.

[Marco Maggi (mrc-mgg)]

Derick Eddington wrote:
>I was using the POSIX docs earlier, and these fields aren't in POSIX
>(though it seems to leave it open so the standard fields could be any
>resolution), but I bet it'd be relatively easy to #ifdef them portably.

The Single UNIX Specification has the same opinion.

<http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/stat.h.html>
<http://www.unix.org/version3/online.html>

[Abdulaziz Ghuloum (aghuloum)]

Fixed in 1683.

[Abdulaziz Ghuloum (aghuloum)]

Neah, that didn't go so well with linux. Don't update yet.

[Abdulaziz Ghuloum (aghuloum)]

Fixed in 1684.