[net.micro.att] Notes on the UNIX-PC

stevet@ihuxl.UUCP (Turpin) (02/07/86)

There are a couple of problems that I've encountered with the UNIX PC.  One
concerns fsck.  As the computer comes from the factory, it will not save
unreferenced files that fsck finds.  The reason for this is there is no
lost+found directory in the root node.  Also, the install diskettes do not make
this directory.  They should!!

Anyone who does not have this directory on their system should do:
$ mkdir /lost+found

If you have more than one filesystem on your hard disk you need to make the
lost+found directory in the root of each filesystem.

Another problem I've encountered is that the "Restore from floppy" command
bombs out whenever you try to run it.  I execute "Show and Restore files" and
the program reads the floppy and makes the list from which I am to pick the
files that I want to restore.  As soon I hit [ENTER], the program execs another
program which "core dumps".  I haven't taken the time to find out which file
this is that bombs out.  Maybe someone else has had this problem.  I am using
the 3.0 upgrade of the utilities.  Anymore, I just run cpio from the shell.

One other thing I've noticed, is that the PC uses the same icon for the printer
as it uses for the floppy disk.  This is somewhat confusing at times.  You
think that the floppy is not closed, but it is actually a printer file that is
open or hosed up.
 
On the plus side, the 3.0 software has a lot of nice enhancements.  The
async_main program now has auto-logon, screen-print, break key, etc.  the
screen-print requires a bit-mapped printer.  There is also improvements in the 
printer utilities.  The ability to read, write and format MS-DOS diskettes is
also very nice.

mjs@sfsup.UUCP (M.J.Shannon) (02/07/86)

> 
> There are a couple of problems that I've encountered with the UNIX PC.  One
> concerns fsck.  As the computer comes from the factory, it will not save
> unreferenced files that fsck finds.  The reason for this is there is no
> lost+found directory in the root node.  Also, the install diskettes do not make
> this directory.  They should!!
> 
> Anyone who does not have this directory on their system should do:
> $ mkdir /lost+found

Further, you should also:
	$ cd /lost+found
	$ for i in 1 2 3 4 5 6 7 8
	>>do
	>>	for j in 1 2 3 4 5 6 7 8
	>>	do
	>>		touch ${i}${j}
	>>	done
	>>done
	$ rm *
What this does is allocate real blocks to the directory itself.  Why you need
this is fsck cannot allocate blocks from the filesystem that's damaged.

> If you have more than one filesystem on your hard disk you need to make the
> lost+found directory in the root of each filesystem.

Hope this saves some of your files....

	Marty Shannon
	SF G-213 x6063
	sfsup!mjs

allyn@sdcsvax.UUCP (Allyn Fratkin) (02/08/86)

In article <1709@ihuxl.UUCP>, stevet@ihuxl.UUCP (Turpin) writes:
> 
> Anyone who does not have this directory on their system should do:
> $ mkdir /lost+found

There is more to it than this.  Fsck will not allocate directory entries
(I guess it is worried about accdentally extending the size of lost+found
to the next block).  Anyway, you have to have empty slots already.
So you should also do this:
$ cd /lost+found
$ pwd	# verify cd worked.  disastrous results follow if cd failed
$ touch a1 2 3 4 5 6 7 8 99 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
$ rm *

This makes 30 empty slots in /lost+found available to fsck for file
recovery.

> If you have more than one filesystem on your hard disk you need to make the
> lost+found directory in the root of each filesystem.

You should do this entire procedure for the root of all mountable filesystems
(including floppies if you want them to be able to recover from some 
file system damage).

-- 
 From the virtual mind of Allyn Fratkin            allyn@sdcsvax.ucsd.edu    or
                          UCSD EMU/Pascal Project  {ucbvax, decvax, ihnp4}
                          U.C. San Diego                         !sdcsvax!allyn

 "Generally you don't see that kind of behavior in a major appliance."