[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:	VAX and Alpha VMS
Notice:	This is a new VMSnotes, please read note 2.1
Moderator:	VAXAXP::BERNARDO

Created:	Wed Jan 22 1997
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	703
Total number of notes:	3722

513.0. "New V7.1 misfeature - wipes files?" by MARVIN::CARLINI () Wed Apr 23 1997 04:37

Just seen this reported in comp.os.vms:

On VMS V7.1 (I tried VAX, it may happen on Alpha too):

$ CREATE/DIR [.TEST]
$ SET DIR/VERSION=2 [.TEST]
$ SET DEF [.TEST]
$ CREATE TMP.TMP
any-old-stuff
^Z
$ SET FILE/PROT=(RE,RWE,RWE,RWE) TMP.TMP
$ COPY TMP.TMP []

Now you have TMP.TMP;1 and TMP.TMP;2
Now try another copy ...

$ COPY TMP.TMP []
Error opening DISK$USERS:[CARLINI.TEST]TMP.TMP;2 as output
Insufficient privilege or file protection violation
DISK$USERS:[CARLINI.TEST]TMP.TMP;2 not copied

and a DIR shows that TMP.TMP;1 has been deleted and all you have left is
TMP.TMP;2 !!

This is NOT what I expected and does NOT happen with VMS V6.2.
Apparently it started with V7.0, but I don't have one of those handy to check.

Should I QAR this against the XQP or RMS or ... ?

And should it be HIGH or MEDIUM (bit late for SHOWSTOPPER I guess :-) )?

Antonio

T.R	Title	User	Personal Name	Date	Lines
513.1		MOVIES::WIDDOWSON	Rod OpenVMS Engineering. Project Rock	`Wed Apr 23 1997 05:36`	6
	Antonio, does the file turn up after anal/disk/rep ? I think that this is known and long standing, and I think it is in RMS... /rod
513.2		MARVIN::CARLINI		`Wed Apr 23 1997 08:35`	18
	> Antonio, does the file turn up after anal/disk/rep ? Indeed it does. > I think that this is known and long standing, and I think it is in > RMS... It can't be that old since it doesn't happen with V6.2 (or at the very least the bug isn't visible to the user). Care to elaborate on what the underlying problem is and why it is user-visible in V7? Is it worth QARing now that it is visible? Can it be fixed? Cheers, Antonio
513.3		MOVIES::WIDDOWSON	Rod OpenVMS Engineering. Project Rock	`Wed Apr 23 1997 09:47`	14
	Antonio, Yes, please QAR it.... The old and known bug was another one which has been fixed, I have been in touch with the person who fixed that (in about this time frame to see whether this is implicated. > Can it be fixed? I guess if it never used to do that, then the change can be un-made.... /rod
513.4		MARVIN::CARLINI		`Wed Apr 23 1997 11:03`	4
	> Yes, please QAR it.... I just peeked at comp.os.vms again and it looks like Joshua Cope of QTV will be QARing it.
513.5	Amazing how fast word gets around	STAR::COPE		`Wed Apr 23 1997 11:47`	4
	It's EVMS-RAVEN #1051, for those interested. It's a regression starting in OpenVMS 7.0, and only occurs under some unusual circumstances. -Josh
513.6	RMS not the culprit	STAR::EWOODS		`Wed Apr 23 1997 15:18`	25
	Not often one can catch Rod -- especially when it's on his own file system turf. He was thinking of an RMS RENAME problem that was fixed in V7.1. The problem that Joshua Cope has qar'd (thanks) doesn't involve any rename. It is a CREATE of a file where in order to enter this new file because of a VERSION_LIMIT set on the file, requires the deletion of the directory entry of another version (the lowest one) of the file. It is the file system (XQP) that manages all this as part of the $QIO create requested (see section 1.6 of I/O ref. manual). In other words, RMS isn't the culprit (the one responsible for this regression). It issues the $QIO and the NOPRIV error comes back from the file system and the directory entry for the lowest version has already been removed from the directory by the file system -- not RMS. The QAR has been reassigned to the file system. Note that an anal/disk showed that, as expected, the data file has not been deleted. Its directory entry was deleted and it became a "lost file." -- Elinor
513.7	� Guilty !	MOVIES::WIDDOWSON	Rod OpenVMS Engineering. Project Rock	`Fri Apr 25 1997 05:01`	1