file creation timestamps wrong on msdos fs?

[Bruce Evans]

On Mon, 27 Nov 2006, Oliver Fromme wrote:

> Rene Ladan wrote:
> > rene at s000655:~>cd /media/stick
> > rene at s000655:/media/stick>date && touch a-new-dos-file
> > ma 27 nov 2006 10:53:59 CET
> > rene at s000655:/media/stick>ls -lUT a-new-dos-file
> > -rwxr-xr-x  1 rene  wheel  0  1 jan 01:11:23 1970 a-new-dos-file
> >                                     ^^^^^^^^^^^^^
> >
> > Any idea why this happens?  ls and msdosfs themselves seem to be
> > alright.  The access and modification timestamps of msdosfs files are
> > shown correctly.
>
> There seems to be a bug in src/sys/fs/msdosfs/msdosfs_vnops.c
> because of a subtle confusion between what msdosfs calls
> "ctime" (creation time) and what UNIX calls "ctime" (inode
> change time, unsupported by msdosfs).  If your -current is
> older than 2006-10-24, look for these lines:
>
> 	dos2unixtime(dep->de_MDate, dep->de_MTime, 0, &vap->va_mtime);
> 	if (pmp->pm_flags & MSDOSFSMNT_LONGNAME) {
> 		dos2unixtime(dep->de_ADate, 0, 0, &vap->va_atime);
> 		dos2unixtime(dep->de_CDate, dep->de_CTime, dep->de_CHun, &vap->va_ctime);
> 	} else {
> 		vap->va_atime = vap->va_mtime;
> 		vap->va_ctime = vap->va_mtime;
> 	}

That gives a bogus ctime in the MSDOSFSMNT_LONGNAME case.  The bogus
birthtime is apparently given in both cases by using vap->va_birthtime
uninitialized, so it is stack garbage.  va_birthtime isn't referenced by
any file system except ffs, but a few file systems initialize it to
0 by bzero()ing the whole *vap, and least 1 file system initializes
it accidentally correctly using VATTR_NULL().  Grepping in sys/fs
shows bzero()ing for the following file systems:
    devfs, portalfs
This gives the well known date of Dec 31 1969 (0 seconds since the
Epoch in local time East of Greenwich :-).  VATTR_NULL() is used by
xfs.  It gives VNOVAL which which happens to be (time_t)-1 when converted
to a time_t.  This is a better value than 0 for an unsupported time_t
fie.d xfs has an explicit reference to va_birthtime, but only under
#if 0.

> That should fix the output of "ls -lUT" (please report).
> However, the question remains what the vnode's ctime should
> be set to.  There's no such thing as an inode change time
> in FAT's directory entries.  Maybe it should simply be
> copied from the mtime.

There's nothing better.  msdosfs already does this for the
!MSDOSFSMNT_LONGNAME case.   Utilities expect the ctime to be set to
an actual time, so it should't be set to -1 like the btime^H^H^H^Hirthtime.

Bruce