>I think that this may fall into the "hardware abstraction" area. I don't see the information being "restricted" so much as unneeded. The only time that a problem could arise is if the application had to write multiple files to a disk at one time. If you've got enough free space on the drive for a single file, then the cluster size is irrelevant. However, when writing multiple files, then it could come into play.
>
>I think a better illustration of this would be the status of a printer. We've seen the question as to how to determine this from within VFP a number of times. Even winspool.drv itself doesn't know this. Why? Simply because it hands the job over to the driver for the particular printer. It's that driver's responsibility to make this determination and, if a problem exists, notify the user. If a problem does exist, the print job will stay in the queue until either the problem is resolved or the job is deleted.
>
>The big upside to this is that the programmer doesn't have to worry about this stuff and other related deltails. I mean does anyone really miss having to send escape sequences to the printer?
>
>I think that this part of the price of having a pre-emptive multi-tasking operating system. It's the operating system that's in charge, not the application (as it was back in the DOS days). Further, having the operating system in charge is the only way to have a pre-emptive multi-tasking OS. The benefit is that you're largely shielded from some of the details and don't have to worry about it. The drawback is that if you really, really need the information it can be tough, if not impossible, to get to. If one were to find themselves in need of such, the question as to whether or not the information is absolutely essential must be answered.

Gotcha. All seems reasonable to me. It's just those every-so-often situations when you need something you can't get that it becomes irritating. I would agree, tho, that the advantages outweigh the irritants. :-)