From: utzoo!decvax!genradbo!linus!smk
Newsgroups: net.unix-wizards
Title: why squish?
Article-I.D.: linus.1512
Posted: Fri Dec 31 13:47:38 1982
Received: Sat Jan  1 03:12:25 1983

	Let me summarize the squish discussion and then we
can call it quits.  (But from experience, it never is!)
	Those of you who use tar/cpio to do the same thing
will run into trouble if you don't have enough space to hold
a copy of the hierachy you want to move.  Thus, you shell scripts
should first do a df and compare it to the du on the hierarchy.
It's slow and messy and should fail with just a little space
left.  My neighbors have a tight space problem and couldn't
use the tar/cpio solution.
	Except for the .. problem on subdirectories, uusquish
works fine for /usr/spool/uucp.
	Squish is more general purpose and works (recursively
if you want) on directories not containing a mountable file
system.
	Both squish and uusquish have problems when someone happens
to be in the hierarchy you are dealing with, so the best bet
is to run them right after the mounts (and cleanups) in /etc/rc.
For this reason, I would like to see a squish system call.  Only
in the kernel can you check to see if it is OK to do (similar
checking on the mount/umount calls is already there to use).
If a system call were provided, /usr/lib/crontab could run a
find / -file d -a -exec squish {} ";"
every nite.  Squish in this case would simply call the squish
system call (which would look like squish (dirname);)
	Those of you who want to stick to shell scripts, fine.
I don't care.  If you want squish, it's there for you.
Let's stop the bickering.

	BTW--
	Mkdir suffers the similar problems to squish.  If you
kill it at the right moment, the directory is made without the
. and .. entries.  This should be a kernel function also.  Sure,
mkdir works OK, but if there are possible bugs, let's fix them correctly.
Since the kernel understands about . and .., why not move mkdir
there also?
	The System III cpio has a bug which I will post soon.