Date: Sun, 13 Jan 2008 10:10:04 GMT From: David Schultz <das@FreeBSD.org> To: freebsd-bugs@FreeBSD.org Subject: Re: misc/113668: scandir(3) uses st_size of directory in unsupported manner Message-ID: <200801131010.m0DAA4Rj067796@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/113668; it has been noted by GNATS. From: David Schultz <das@FreeBSD.ORG> To: Ed Ravin <eravin@panix.com> Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: misc/113668: scandir(3) uses st_size of directory in unsupported manner Date: Sun, 13 Jan 2008 05:03:10 -0500 In the original Unix, directories were just files. FreeBSD has always supported that philosophy; you can still `cat' a directory, and so it makes sense that st_size gives you the size in bytes. It's not scandir's fault that System V made directories more magical, then POSIX came along and had to cope with it, then the ZFS team exploited the underspecification in POSIX for their own nefarious purposes. :) That said, given that FreeBSD now has ZFS, and some of the ZFS utils probably assume the new ZFS rules for st_size, I guess we ought to do something! Note that this is just a performance problem, since scandir will realloc the array as necessary. However, it does the increases in increments of 10 entries, and it should probably realloc multiplicatively so the amortized cost of the reallocs is linear. I'm not sure what to do about the initial estimate, though. If we really want to support every old st_size value filesystem designers come up with, we need to worry about st_size being too large as well, so we basically shouldn't use it at all...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801131010.m0DAA4Rj067796>