Why Partition a Hard Disk

[Daniel R. Levy]

In article <8424 at smoke.ARPA>, gwyn at smoke.ARPA (Doug Gwyn ) writes:
< In article <66800 at sun.uucp> guy at gorodish.Sun.COM (Guy Harris) writes:
< >Yes, changing the "stat" structure may be painful.  Not changing it may be
< >painful as well....
< A reasonable way to make the change is to introduce a new system call,
< which acts the way one wants (e.g. long st_ino), change the C library
< stat() interface to use the new system call (and change the stat.h
< header at the same time!), then recompile and test all the system
< software at one's leisure.  Old binaries keep working until one is
< finished checking everything out and removes the old system call (if
< ever; usually it is left enabled so customers don't have to recompile
< anything).  Old binaries can fail on long inode numbers, but this is
< no worse than not making the change, and at least the official system
< software has been upgraded to work right.

I see another problem.  Presumably, the change over to a long inode was
accompanied by a change from a V7-type file sytem to a different file system
where directory entries support the long inodes (whether this be BSD 4.3 or
some new kluge).  This means that old binaries which depend on scanning
directories and assume the V7 format (where the open-directory and
read-directory-entry functions are not system calls but rather library
functions implemented with open() and read()) will now fail miserably.

Presuming a BSD 4.3 file system, even if (joy of joys) directory scanning was
implemented with a special system call, old binaries might not have allocated
enough space for new, longer file names.
-- 
|------------Dan Levy------------|  THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY
| Bell Labs Area 61 (R.I.P., TTY)|  AND ARE NOT TO BE IMPUTED TO AT&T.
|        Skokie, Illinois        | 
|-----Path:  att!ttbcad!levy-----|