delorie.com/archives/browse.cgi | search |
From: | sandmann AT clio DOT rice DOT edu (Charles Sandmann) |
Message-Id: | <10301021958.AA05656@clio.rice.edu> |
Subject: | Re: Problem with df reporting the wrong sizes [PATCH] |
To: | djgpp-workers AT delorie DOT com |
Date: | Thu, 2 Jan 2003 13:58:10 -0600 (CST) |
In-Reply-To: | <3E1425A4.FB7DCD6D@phekda.freeserve.co.uk> from "Richard Dawe" at Jan 02, 2003 11:42:28 AM |
X-Mailer: | ELM [version 2.5 PL2] |
Mime-Version: | 1.0 |
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 |
> Incidentally, which solution should I code up? Well, since you are coding it you get to decide. I think you've done enough research on pros and cons to make your own call. > (c) Preferred by Charles: Return 512 as the fundamental block size. Pros: true > in some common cases. Cons: involves scaling numbers again; not true for a > number of common cases - CDs. It should be noted that CDs can also use 512 bytes as the fundamental block size at the SCSI interface level on many machines (Sun, VMS, T64Unix, etc). Not that it matters here ...
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |