MCGUIRE@GRIN1.BITNET ("The Sysco Kid ", McGuire,Ed) (04/14/88)
Actually, Digital has made significant changes to disk structures in the past, both in VMS and in RSTS/E. This precedent would make me very reluctant to write any code that depends upon the internal structure of a directory file. In VMS they added support for longer filenames, access control lists, and so forth. I don't normally program at that level on VMS but I'd imagine that the changes in data structures required for this support could break programs that make assumptions about their layout and size. This could apply both to the directory structure and also to the retrieval and security database (INDEXF.SYS). In RSTS/E they added `large file' support to a structure which originally limited the size of a file to 32767 or 65535 due to the size of a 16-bit word. Anyone who had written code to look at the directory structure and retrieval pointers had to rewrite it or it would die when it encountered a large file. Later, they redesigned the directory structure, removing retrieval pointers from the master file directory and creating a new hierarchical retrieval structure. This change broke any program that took advantage of knowledge of the structure of directory or retrieval blocks. Any documentation that Digital provides on the layout of those data structures is sketchy. This has always encouraged folks to use system services to manipulate the disk structure instead. Digital appears to make the effort to maintain compatibility of system services from release to release. Conclusion: Digital does make changes to disk directory and retrieval data structures. Programs that call system services are much less likely to break later than programs that assume a particular internal implementation of disk structure. Ed