Date: Thu, 28 Dec 2006 13:19:21 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-current@FreeBSD.ORG, uspoerlein@gmail.com Subject: Re: msdosfs and cd9660: stat(2) returns garbled birthtime Message-ID: <200612281219.kBSCJLEV046635@lurza.secnetix.de> In-Reply-To: <7ad7ddd90612270810o6ebaf8c8mdbade512c1eb096f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612281219.kBSCJLEV046635>