Re: msdosfs and cd9660: stat(2) returns garbled birthtime

From: Oliver Fromme <olli_at_lurza.secnetix.de>
Date: Thu, 28 Dec 2006 13:19:21 +0100 (CET)
Ulrich Spoerlein wrote:
 > Oliver Fromme wrote:
 > > Please see PR kern/106018.  It fixes the msdosfs case;
 > > it has already been committed a few weeks ago.
 > > 
 > > I haven't looked at the cd9660 code, but if you see
 > > similar problems there, then I guess it needs a similar
 > > fix.  ;-)
 > 
 > Ah, sorry for not testing this on current (I used RELENG_6).

Well, this is the "-current" mailing list, so I assumed
you were using (an older version of) -current a.k.a. HEAD,
not RELENG_6 which is -stable.

I haven't checked whether the patch from kern/106018 has
been MFCed.  Maybe it wasn't deemed safe enough for
inclusion during the 6.2 code freeze (it's a quite trivial
patch, though).

 > Changeing each filesystem code to do this is somewhat ugly.

I don't think it is ugly.  It's up to each file system to
decide which data makes sense to use for the birthtime.

 > Though I
 > don't think that we will grow significantly more statfs fields over
 > time, the syscall should probably first bzero() the struct and let the
 > fs-specific code fill in the/some blanks.

That would mean that zero will be returned for fields that
are not filled in by the FS-specific code.  That's wrong.
In most cases it probably makes more sense to return -1
for unsupported fields, rather than 0.  And in some cases,
a different value should be copied.  (For example, FAT does
not support ctime, but it would be wrong to return 0 or -1
for it.  Instead, the most useful thing to do is copy the
mtime value for the ctime.)

The real fix is to have every FS fill in _all_ fields with
reasonable values.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

(On the statement print "42 monkeys" + "1 snake":)  By the way,
both perl and Python get this wrong.  Perl gives 43 and Python
gives "42 monkeys1 snake", when the answer is clearly "41 monkeys
and 1 fat snake".        -- Jim Fulton
Received on Thu Dec 28 2006 - 11:19:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:04 UTC