<<< VMSZOO::DISK$NOTES:[NOTES$LIBRARY]VMS_POSIX.NOTE;2 >>> -< POSIX for OpenVMS - Public forum >- ================================================================================ Note 1320.5 Can default device be remote NFS filesystem?... 5 of 5 LASSIE::CORENZWIT "stuck in postcrypt queue" 74 lines 27-JUN-1996 14:04 -< unsupported; just don't do this >- -------------------------------------------------------------------------------- Mapping a UCX NFS client device as a VMS POSIX file system is not supported. This is documented in the UCX Release Notes. Some years ago I sent mail to the VMS POSIX engineering group advising them to also include this restriction in their release notes. I do not know if they did so. This system crashing bug is only part of the reason for the restriction. The other part is that the very idea is completely bonkers for anyone who has a good understanding of what the VMS POSIX file system is and what the UCX NFS client is. One reason at a time: 1. System crash: This is caused by POSIX cloning of WCBs when a fork process is created. The WCBs for a UCX NFS client device include some extra fields that POSIX knows nothing about. Hence the extra fields do not get cloned. Hence the system crash when the client tries to access these fields. The problem needs to be fixed in POSIX. POSIX already fixed the very same problem for DECdfs client devices by setting the shared WCB bit instead of cloning WCBs for DFS client devices. The problem here is that DECdfs has a bug in how it handles the transaction count for shared WCBs, and POSIX acquired a corresponding bug to enable it to work with DECdfs. In order for POSIX to be fixed to work with UCX, the DECdfs bug must also be fixed. Something must be done between POSIX and DECdfs engineering teams and support people to coordinate patches to maintain compatibility between pre-fix and post-fix versions of POSIX and DECdfs. There are further complications about coordinating cooperating changes in UCX and in VMS if the change is to be made as free as possible of cross-version incompatibilities and other uglinesses. In the pessimism I have acquired over many years of software engineering, I personally have very little hope of seeing any of this happen in my lifetime. Of course, I would like very much to be wrong on this point. But if I were wrong, it wouldn't eliminate the other reason. 2. Why this won't work satisfactorily even if the system crash is fixed: The NFS client is a machine for making a UNIX file system resemble a VMS filesystem. The POSIX mapping is a machine for making a VMS file system look like a UNIX file system. When you grind a file system through both of these machines in succession, what comes out doesn't look quite exactly like either a UNIX or a VMS file system. This is demonstrated in .4. Hartmut is looking at a bunch of files with mixed case names. The UCX client has turned these into a bunch of files with upper case names and $'s used as escape characters. POSIX has turned these into a bunch of files with lower case names and $'s used as escape characters. POSIX could be enhanced to recognize that these names should be changed back to mixed case names. However, some other anomaly involving file attributes instead of names would turn up. It would make more sense to implement an NFS client in POSIX itself, rather than use the UCX client. This would be a machine for making a UNIX filesystem look like a UNIX file system. What could be more reasonable? Creating and mapping a container file system on an NFS client device positively won't work and can never be made to work, because the NFS client dynamically generates FIDs, which are only good for as long as the device remains mounted. ANALYZE CONTAINER /REPAIR would have to be run every time the device was remounted. Two different hosts running VMS POSIX would not be able to look at the files at the same time. And, BTW, the UNIX server host would not easily be able to look at files locally at all, though this would not be because of the impermanent FIDs. Julie UCX engineer, NFS team, with primary responsibility for NFS client also, in a former life, DECdfs engineer