brownrigg@kuhub.cc.ukans.edu (10/03/90)
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". 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). What is the origin of this file system? 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)? ANy gurus out there willing to enlighten the stupid? Rick Brownrigg
guy@auspex.auspex.com (Guy Harris) (10/04/90)
>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.
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/04/90)
In article <25866.27091187@kuhub.cc.ukans.edu> brownrigg@kuhub.cc.ukans.edu writes: >What is the origin of this file system? SGI came up with EFS on their own, although there are similar extent- based filesystems available from other vendors of UNIXy systems. >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)? More and more, some sort of network access is becoming dominant on "real" computers (as opposed to IBM PCs). NFS certainly has the lead there, despite its many deficiencies. The kernel is supposed to handle accessing different types of filesystem for your application, so it shouldn't really matter what kind exists. I suspect the problem you reported was due to the application trying to interpret the contents of a directory itself instead of relying on the getdents() system call to fetch entries from a directory (typically done through use of opendir()/readdir()/etc.).
bruce@segue.segue.com (Bruce Adler) (10/05/90)
Where can I get information regarding IBM's JFS (short of buying a complete system)? -- bruce@segue.com, ism.isc.com!segue!bruce, aero.org!segue!bruce
prc@erbe.se (Robert Claeson) (10/05/90)
In a recent article guy@auspex.auspex.com (Guy Harris) writes: :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"). I'm using one of those systems with multiple file system types in use at the same time, with different directory layouts and file name lengths. Kermit is only one of the packages that I've had to modify to use POSIX directory functions. In fact, most PD software seems to assume that everything that's System V is the ancient Release 2, which only supported the old V7 file system. :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. Is there any way that a program can check how long a file name can be before creating it in a directory without actually trying to create a file first? -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se | Perverse mailers: rclaeson%erbe.se@encore.com These opinions reflect my personal views and not those of my employer.
jtc@van-bc.wimsey.bc.ca (J.T. Conklin) (10/06/90)
In article <1822@hulda.erbe.se> prc@erbe.se (Robert Claeson) writes: >Is there any way that a program can check how long a file name can be >before creating it in a directory without actually trying to create a >file first? > Yes, If your system provides pathconf(): maxlen = pathconf ("/usr/spool/foo", _PC_NAME_MAX); --jtc -- J.T. Conklin UniFax Communications Inc. ...!{uunet,ubc-cs}!van-bc!jtc, jtc@wimsey.bc.ca