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.