Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Unix file systems (UFS, SVFS, EFS....)?
Message-ID: <4136@auspex.auspex.com>
Date: 3 Oct 90 18:37:04 GMT
References: <25866.27091187@kuhub.cc.ukans.edu>
Organization: Auspex Systems, Santa Clara
Lines: 54

>A/UX supports two file systems:  UFS (BSD4.2, the "preferred" file
>system), and SVFS (system 5, for compatability).  THis point was
>poignantly driven home while trying to discover a bug in "kermit"
>with wildcard "sends".

Did Kermit, perchance, expand the wildcards itself, and think that it
could enumerate the names in a directory by reading the directory with
"read()" under the assumption that the directory was filled up with
V7-style 16-byte directory entries?

That was true a long time ago, but any programmer that *still* thinks
that's ok had better think again, and think hard, and then start using
"opendir()", "readdir()", etc. (for those ancient systems that lack
them, several implementations exist for V7-style directories; #ifdefs
can deal with the problem of the old-style <sys/dir.h> with "struct
direct" and the new-style POSIX-flavored <dirent.h> with "struct
dirent").

>Lo and behold, Kermit on our SGI PErsonal IRIS displays the same problem,
>and it seems to have yet another file system, refered to as "EFS" 
>(extent file system).

Yup, UFS definitely does *NOT* have V7-style directories, and I don't
think EFS does.

>What is the origin of this file system?

SGI invented it.

>What is the "predominant" file system on the plethora of Unix boxes out
>there (i.e, is there an emerging concensus about which way to go)?

Well, a while ago I might have said "almost everybody's moving towards
UFS", but, although lots of people (including AT&T, with S5R4) have
adopted UFS, people are coming up with even newer file systems
(Veritas's VxFS, IBM's J(ournaling)FS, Transarc's Episode; all three are
similar, in that they use a transaction log to harden the file system
rather than using synchronous writes to file system data structures).

(On top of that, there are the various distributed file systems, such as
NFS, RFS, and AFS; those sit under the same procedural interface as
local on-disk file systems.  They tend not to support the old-style "use
read()" interface to directories, either.

And don't forget the nonfile systems, such as "/proc", which look like
file systems but are actually filesystemish views of things such as the
system process table.)

However, all the standard POSIX-style calls ("open()", "close()",
"read()", "write()", etc.  for I/O to/from files, and "opendir()",
"readdir()", etc. for I from directories, as well as "mkdir()",
"rmdir()", "rename()", "state()", and the like) should work on all those
file systems; use them, don't make your program depend on any aspect of
a particular file system that it doesn't absolutely have to.