Date: Tue, 28 Nov 2006 20:31:37 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Oliver Fromme <olli@lurza.secnetix.de> Cc: freebsd-fs@freebsd.org Subject: Re: file creation timestamps wrong on msdos fs? Message-ID: <20061128200917.W1917@delplex.bde.org> In-Reply-To: <200611271340.kARDed3F033672@lurza.secnetix.de> References: <200611271340.kARDed3F033672@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 27 Nov 2006, Oliver Fromme wrote:
> Rene Ladan wrote:
> > rene@s000655:~>cd /media/stick
> > rene@s000655:/media/stick>date && touch a-new-dos-file
> > ma 27 nov 2006 10:53:59 CET
> > rene@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061128200917.W1917>