Help! modifying os to support >14 char filenames (sys V.3)

[Jeff Beadles]

pcg at cs.aber.ac.uk (Piercarlo Grandi) babbles:
|On 7 Sep 90 07:35:20 GMT, cliff at motcsd.csd.mot.com (cliff.rodriguez) said:
|
|cliff> We are working on a project to convert our system V based system
|cliff> (ver 3) from 14 char file names to something much larger.
|
|Do you *really* need much larger? Why? If something like 30 instead of
|14 would do, an easy hack exists.

We could use a few less "hacks". :-)

|cliff> Has anyone out there done this, or heard it done?  I need to know
|cliff> if this is going to be the slow tedious task I think it is.
|
|Well, this can be (and has been) done in two ways:
|
|1) keeping the current organization, but just extending the size limit.
|For example, you could have directory entries that are 32 bytes long,
|for 30 byte file names, or 64 bytes long, for 62 byte file names. This
|does not require much more than changing a #define or two and
|recompiling the kernel, the dirent library, and a few applications that
|do not use it (mkfs, fsck, etc...). It does make directories grow in
|size, but I think that's not too important -- many directories are well
|under 512 bytes, i.e. 32 entries, and doubling the entry size to 32
|bytes would not consume any additional disk or memory at all in this
|case.
...

This is **NOT** true.  There are hard-coded user programs that depend on a
14 character filename limit!  It's by no means as easy as changing a
#define or two.

For example, what will this code fragment do with >14 character filenames?

...
	for(i=0; i<14; i++)
		if(*xx)
			*yy++ = *xx++;
		else
			break;
	*yy ='\0';
...

This is typical of parts of the SYSV 3.2 code.  True, this is not an robust way
to handle this, but it is typical of the code.  The ONLY way to find these
sorts of problems is by inspection or searching.


	-Jeff
-- 
Jeff Beadles  jeff at onion.pdx.com