From: Martin Stromberg Message-Id: <200111280854.JAA06029@lws256.lu.erisoft.se> Subject: Re: RESEND: Patch to computer st_blksize in struct stat To: djgpp-workers AT delorie DOT com Date: Wed, 28 Nov 2001 09:54:19 +0100 (MET) In-Reply-To: from "Eli Zaretskii" at Nov 28, 2001 10:30:32 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > > CVS CVS+st_blksize > > ------------------------------------------------------------------ > > Floppy disk with 285 files in directory: 0.00s 0.06s > > CD-ROM disc with 242 files in directory: 0.22s 0.28s > > Hard disk with 285 files in directory: 0.17s 0.22s > > Network drive with 257 files in directory: 6.28s 6.33s > > [...] > > So should I call statfs() by default for all drives? > > I'd prefer not to do that for floppies and networked drives, even > though the above data suggests the slow-down is negligible in the > normal case. The reason is that floppies could have damaged FATs that > could fail stat where it previously would succeed, and networked > drives could incur delays due to network problems. Since the block > size on a floppy is almost always known in advance, and for networked > drives the size is of no practical use, it doesn't seem like a risk > worth taking. Is a ZIP disk a floppy? If so I think we should get the correct block size from it. > Another btw is that the new Posix draft defined a standard function > called statvfs (and another one called fstatvfs). Would someone > consider writing these, as more-or-less trivial wrappers for statfs? No problem, if you show me where to get this draft. Note that my DJGPP setup is without a computer right now, so it'll take some weeks before I'll dig in. So if anyone else feels like to take it on, (s)he's welcome to do so. Right, MartinS