On Thu, 03 Dec 1998 10:51:11 GMT, you said:
So you need 7Mb slack for installation - seems not unreasonable to
me. I
guess the best thing to do would be to check how much space is actually
free and act accordingly. Ultimate paranoia would account for the
possibility that it may not be possible to install a newer package because
it is bigger than the previous one.
And on some systems and configurations, you can't even trust 'du' to
give you valid numbers to compare. Consider these:
1) Installing off an NFS-mounted disk that has a 512-byte fragment
size onto a disk that has a 4K fragment size (and thus takes a bit more
room per each file....)
2) Installing from a file system that doesn't have compression into
a nearly full filesystem that *is* compressed - I've often been able
to drop a 75M package into an AIX compressed JFS and have 'df' only
report 40M more used.
3) AIX has a 'chfs' command - if you have unallocated 4M chunks on a
disk[1], you can add them into a filesystem on the fly. So it's pretty
common to start an install into /usr/local, and just do a few 'chfs'
as it progresses to keep on step ahead, and end up with /usr/local still
close to full, and as few more disk slices allocated as possible.
Moral - the only truly safe way to do it is to check the return code
of write().
/Valdis
[1] Actually, the free space doesn't even have to be on the same disk,
just in the same *group* of disks... I have /home and 2 other filesystems
all spread out over 3 disks on this machine, and a gig or so free space
that I can glue on any of those (or create new ones) on the fly. Disk
management has come a LONG way since BSD 4.2 disk partition labels (at least
for some vendors ;)