Unix file systems (UFS, SVFS, EFS....)?

Robert Claeson prc at erbe.se
Fri Oct 5 22:07:17 AEST 1990


In a recent article guy at 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 at erbe.se
ERBE DATA AB                    |      Dumb mailers: rclaeson%erbe.se at sunet.se
                                |  Perverse mailers: rclaeson%erbe.se at encore.com
These opinions reflect my personal views and not those of my employer.



More information about the Comp.unix.questions mailing list