Path: utzoo!mnetor!uunet!husc6!mit-eddie!smu.UUCP!spray
From: spray@smu.UUCP (Robert D Spray)
Newsgroups: comp.emacs
Subject: Write protected on VMS 4.6
Message-ID: <8712181422.AA29301@a.cs.uiuc.edu>
Date: 18 Dec 87 11:05:40 GMT
Sender: nessus@eddie.MIT.EDU
Lines: 39

A colleague is having difficulties installing GNUEmacs on a 
MicroVAX running uVMS 4.6. He writes:
-------
We have received GNUEMACS version 18.49.1 for our MicroVMS system (v4.6).
After doing the install, there seems to be major problems.

Whenever you enter gnuemacs with an existing file name specified, the editor
starts up and the message "file write-protected" is displayed. This happens
for every existing file in every directory no matter what protection is 
actually set on the file (even when set to: S:RWED, O:RWED, G:RWED, W:RWED).
When a non-existing filename is specified upon entry, the message "file not
found and directory write-protected" is displayed. This happens even though
the directory is observed NOT to be write-protected. The same behavior occurs
when doing a "^X^F" find file.If a file name is not specified, the editor
starts in "scratch" buffer, but will not let you save anything to a file. For
example, if you try to save the scratch buffer to a nonexistant file named
TEST.DAT a message appears stating "File test.dat is write-protected; try to
save anyway? (yes or no)".Note, this message appears even though there is no
way TEST.DAT can be write-protected, it doesn't even exist yet! Typing a yes
in response the above question gives you: "Doing chmod: no such file or
directory USER1:[TEST]TEST.DAT". If an attempt is made to leave gnuemacs with 
the scratch buffer still unsaved, the editor informs you and asks to save.
Again the message appears about the nonexistant filename being write-protected,
and you are asked to try to save it anyway. If you answer yes, this time the
file is saved with strange prefixes and a suffix added to the filename to
produce "_$TEST.DAT$;1". This appears to happen only with an unsaved scratch 
buffer and isn't be exhibited with other named buffers.

Attempts to relink the code have proved unsuccessful with the existing .OBJ
files (numerous linker warnings are displayed). And, we presently do not have
a C compiler available to recompile the sources.
-------
Any clues on how to fix this would be most appreciated.

Rob Spray
Electrospace Systems Inc.
214-669-8899
...convex!smu!spray
spray%smu@relay.cs.net