Long file names for ESIX

[Chin Fang]

Hi everyone,
 
After I saw the posting from Jeff of ESIX tech support, I immediately decided 
to give it a try.  The following are a list of problems that I have encoutered
and some new discoveries that I have found along the way.  Before I go on, 
I would like to invite other ESIX users sharing your experience.  If anyone
has succeded, please post.  
 
My motivation is very simple,  Stanford's unix machines are all Berkeley type,
so every now and then when I do file (src in particular), you can imagine my
trouble of shortening file names.
 
First, problems:
 
1. the -sysv switch no longer the controlling switch for SysV format or
   Berkeley long file name format (255 char.)  Another ESIX user Mr. Yergeau
   of EE Department also found that out and informed me too.

2. The controlling switch turns out to be the -S switch for /etc/ffs/mkfs.
   The way to tell is invoking /etc/ffs/newfs -v -N /dev/rdsk/0s0 and you 
   will immediately see /etc/ffs/mkfs -S -N -R 4 even though in release notes
   and the usuage output from newfs to stdout /etc/ffs/mkfs is mentioned as
   default, it IS NOT!
 
3. I don't see a way to prevent /etc/ffs/newfs from invoking /etc/ffs/mkfs 
   without the -S switch. 
 
4. My machine, a 3 year old 20 Mhz 386 with 8 megs mem and 387, would trash
   the boot sector of a floppy whenever I mount it to be both rw.  So what I
   did was to use gnu emacs 18.55 reading in dd image of both the first and 2nd
   boot disk, edit out the -sysv switch from INSTALL from the dd image of the
   1st boot disk, and -S from the dd image of the 2nd boot disk, and then 
   dd them back to back up floppies.

5. Using back up floppies thus created, I could finish the first two floppies
   without any symptoms.  However, after prompted reboot the system, I didn't
   get the familar "Are you installing from tape" prompt, instead, my machine
   kept booting itself after each memory parity check.  I did once quick 
   recovery reinstallation, NO use!
 
6. I installed the normal 14 char ESIX FFS, and used emacs to edit 
   /etc/ffs/newfs on the hd, overwrote the -S switch in the binary file with
   blanks, and tried to use it to rebuild a file system for /usr.  Either I 
   did something wrong or other things I did not know about, the entire 
   ESIX system installed on my hd became non-functional.  ( I got a panic and
   memory dump  right after I did the file system manual rebuild).
 
7. ESIX release notes and what I found from playing with the two utilities 
   are not totally consistent. ie. Doc says one thing, the utilities do another
   if you poking into the binary using a binary editor or emacs, you will agree
   with me even more.  So obviously, after Mike Bert(?  the gentleman who 
   implemented Berkeley FFS for ESIX and left to join Unisys not long ago) 
   someone at ESIX must have changed the entire file system code without 
   proper doc the mods.
 
Well, I pretty much said my discoveries in the problem section.  So I will stop
here.  I am out of ideas to try now.  It would be very helpful if people who
have rebuilt the true Berkeley FFS on their primary hds come out and share
their experience.  I hope the above info could be useful if no one have ever
attempted so far.  I also would like to acknowledge three persons for their
info:  Mr. Dan Yergeau of Stanford's EE Department, he gave me most of the hints
       Jeff Eliss and Jeff Row of ESIX Tech Support, their info is out of date
       but their friendly and helpful attatitude never changes. 
 
Chin Fang
Mechanical Engineering Department
Stanford University
fangchin at portia.stanford.edu