Finder ulimit/Compactor1.3

[Richard Todd]

weier at twolf4.CE.YALE.EDU (Richard Weier) writes:

>I attempted to unpack a file using Compactor Pro 1.3 under A/UX.  The 
>unpacked file would be about 10 Meg.  There was plenty of space on the disk
>but I got a message saying "insufficient space on this volume".

   Hmm.  I can think of two possibilities.  The first is that you've still
got the "BSD free space reserve" set on your filesystems.  On BSD-style
filesystems (the sort A/UX uses by default), 10% of the filesystem is
reserved for the superuser only; mere peons can't touch that space.  The
reasoning is that when a BSD filesystem gets over 90% full, the performance
of file accesses goes down, so ideally one doesn't want the partition to
ever get that full.  However, in this non-ideal world where new disk drives
take large chunks out of my bank account :-), one is sometimes forced to
make do with using the last bit of free space on a filesystem.  The
"tunefs" command can be used to make the "free space reserve" on a
filesystem go to 0, so ordinary users can use all the space.
   However, this probably isn't your problem.  You see, df is rigged so
that it only shows the amount of space you can actually access (i.e. if
you're not root, it cleverly fakes the free space figures so you can only
see the 90% of the FS that's open to you).  So the only way you could see
"space that isn't there" is if you did the df as root and then did the 
un-Compact as an ordinary user.  So let's go on to possibility #2:

>1) Is there some kind of ulimit imposed on the finder?  I could not find anything like this in the man pages.

Not a ulimit, but a rather nasty mismatch between the expectations MacOS 
programs have of how free space on a filesystem works and how it works under
Unix.  You see, under Unix the multiple partitions on one's disk(s) are all
linked together into one single directory tree, so the ordinary user won't
even notice that there are multiple partitions, except for one thing: free
disk space.  How much free disk space you have available to create a file
depends on what directory (actually, what partition) you're on when you 
do it.  Now, the unified Unix directory tree starting from / on down is
made to appear to MacOS programs as a single MacOS partition called "/".  
But on "real" MacOS partitions, it doesn't matter what directory you're in
when you check the free space, as it's all one big partition.  So what's 
happening is that Compacter Pro is helpfully checking the free space on 
the MacOS partition "/" for you, which happens to be equivalent to checking
the free space on the root Unix partition.  So it was objecting that there
wasn't 10M free on the root Unix partition, even though there was free
space where you were planning to unpack the files.  
   So what can you do about this?  Not a lot, alas :-(.  The method I use
is to set aside a section of one hard disk as a genuine MacOS partition for
use in such situations (when you need a good bit of temp. space for
un-Compacting, etc.)  
-- 
Richard Todd	rmtodd at uokmax.ecn.uoknor.edu     rmtodd at chinet.chi.il.us
	rmtodd at servalan.uucp
Motorola Skates On Intel's Head!