EVERHART%ARISIA@rca.com.UUCP (02/19/87)
I received a phone call from Paul Rapacholi who is working in Wollengong, Australia (tel. 61-42-745011 x 5444 for the REAL adventurous) and reports a number of bugs in VMS 4.5, one of which can silently trash thousands of files on your disks. The disk corruption problem occurs on index file extension on cluster mounted disks and has hit Paul a couple times so far. It appears that when two processors are creating files on a volume at the same time, the index file gets two extensions, the second of which goes up the creek whenever a cluster member reboots. Somehow it seems one of the processors uses the wrong extension or loses track of what extension to use and when a cluster node crashes or is rebooted and the cluster resynchronizes, the disk shows huge amounts of garbage. Typically this starts at some file ID which is the first file of an index file extension. The index file extension is totally corrupted, and you don't see the damage until there's a reboot. You can get error messages like "unsupported file structure" then. According to a DEC Australia guy, there was a major change in the XQP to lock manager change in VMS 4.5 which may have something to do with the appearance of the problem for the 4.5 version. A workaround is to always INIT a disk with a big index file (and use VMS Backup a lot, to tape.) The other bugs he reports are less serious... For example, if you have an account with a quota of 1000 blocks or so and write into it with a process with EXQUOTA, you get device full errors after about 25000 blocks (even though the device is NOT full). Another one was that if your account password is "password" then the access via nodename"account password":: fails, where nodename"account PASSWORD":: succeeds. VMS reports "invalid node" in the first case... could be some code that checks against "password" since VMS replaces the real password with that string in some reports. Paul hasn't checked to see if a password of "..." also fails (RSX uses that as its default report)... He asked me to post this info to warn others of the dangers... Glenn Everhart