Hello,

As I wrote some weeks ago on the codalist, I had been working on porting
Coda (server) to Solaris. Now, my test server ran successfully, it passed
the simple practical tests: the Linux client compiled from the patched
source could connect to the server, create, lookup and delete files,
directories, reintegrate. Neither the server, nor the client crashed :-).

The server was a Solaris 7, UltraSPARC, source compiled with gcc 2.8.1,
the client was a Linux 2.2.9, i586, source compiled with gcc 2.95.1.

Due to my changes on how to include system header files, I might've 
messed up the BSD/Windows part!

Coda 5.3.1 was already ported to Solaris, however in my opinion it was
only a very quick hack: building new sotware with ucblib is highly
discouraged by Sun itself.

Therefore my patch contains the following new features and fixes:

- ndbm support
- fcntl file locking support
- unified wait3 (thanks to the flexibility of Linux), etc. callings
- shell script fixes (/bin/sh on Solaris is a Bourne shell)

Also, I've tried to push the source into the direction of better
portability via autoconf.

IMHO, the success of Coda depends on two key questions (besides the
natural requirements of being stable and having good performance):

- portability and ported to all of the main UNIX flavors
 
  In my experience, labs and universities usually have a mixed
  environment: all kind of Unix sytems (Linux, *BSD, Solaris, AIX,
  HP-UX, Irix, etc.) mixed with Windows 95/98/NT and other OSes.
  Even when Coda is accepted in BSD and Linux, Coda won't be used
  widely without ported to the commercial Unix versions.
  Hey, still nobody is going to replace for example a good old 
  SPARCCenter 2000 file server workhorse with Linux!

  Therefore the code should at least be made as easily portable
  as possible: instead of depending on the OS (ifdef __linux__), one
  should depend on features (ifdef HAVE_XXX). 

- security

  Besides authentications issues, coda should include real encryption with
  encryption-type negotiation among the servers and the clients. The best
  solution would be if it was achieved by making it possible to link coda
  with a free crypto library, for example with the one from the OpenSSL
  toolkit.


Best regards,
Jozsef Kadlecsik  
-
E-mail  : kadlec_at_blackhole.kfki.hu, kadlec_at_sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary