weier@twolf4.CE.YALE.EDU (Richard Weier) (03/11/91)
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". 1) Is there some kind of ulimit imposed on the finder? I could not find anything like this in the man pages. 2) Or is this just because compactor Pro is not 32-bit clean? Richard Weier weier@twolf.ce.yale.edu
rmtodd@servalan.uucp (Richard Todd) (03/11/91)
weier@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@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp Motorola Skates On Intel's Head!
urlichs@smurf.sub.org (Matthias Urlichs) (03/11/91)
In comp.unix.aux, article <29400@cs.yale.edu>,
weier@twolf.ce.yale.edu 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".
<
< 2) Or is this just because compactor Pro is not 32-bit clean?
<
It gets confused as to whether HFS is available, uses the MFS calls, and
gets confused because of compatibility.
Alternate explanation: You're unpacking onto an A/UX volume other than the
root partition, and while there's enough free space where you're unpacking
onto, the root doesn't have enough free space.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/