edt and file locking
Bob Koehler
In article <42ora6$3...@rzsun02.rrz.uni-hamburg.de>, Phillip Helbig <phe...@hs.uni-hamburg.de> writes:
>By accident I was editing a file with EDT on a VAX (VMS 5.5-2) and
>when I returned to what I thought was the same session after checking
>email on another machine, I noticed that I wasn't in the editor. So
>I called EDT again, and continued editing. I hadn't made any changes
>yet, so I didn't notice that I was editing the same file on two
>different machines, having mistakenly returned to a session on
>another VAX where I happened to be in the same directory (on the
>same, shared, disk, of course).
>
>It's obvious that this is undesirable behaviour. Shouldn't I get
>something like `file currently locked by another user' or something?
>Is this behaviour still there in newer VMS versions? Is there an
>elegant way to prevent this undesired behaviour?
>
Its not in the least bit obvious. EDT only reads the original file, then
closes it. Work is done in a temporary file, which is renamed to the output
file name (usually next version of the original name) on write.
Of all the systems I've worked on, I've never seen an editor that kept the
original file locked as you wish. There are lots of legitimate needs to keep
read access available to that original file.
------------------------------------------------------------------------------
Bob Koehler |
koe...@bessta.gsfc.nasa.gov | rkoe...@author.gsfc.nasa.gov
Phillip Helbig
when I returned to what I thought was the same session after checking
email on another machine, I noticed that I wasn't in the editor. So
I called EDT again, and continued editing. I hadn't made any changes
yet, so I didn't notice that I was editing the same file on two
different machines, having mistakenly returned to a session on
another VAX where I happened to be in the same directory (on the
same, shared, disk, of course).
It's obvious that this is undesirable behaviour. Shouldn't I get
something like `file currently locked by another user' or something?
Is this behaviour still there in newer VMS versions? Is there an
elegant way to prevent this undesired behaviour?
Phillip Helbig Tel. .............. +49 40 7252 4110
Hamburger Sternwarte Email .... phe...@hs.uni-hamburg.de
Gojenbergsweg 112 Fax ............... +49 40 7252 4198
D-21029 Hamburg Telex ............... 217884 hamst d
Phillip Helbig
>In article <42ora6$3...@rzsun02.rrz.uni-hamburg.de>, Phillip Helbig <phe...@hs.uni-hamburg.de> writes:
>>By accident I was editing a file with EDT on a VAX (VMS 5.5-2) and
>>when I returned to what I thought was the same session after checking
>>email on another machine, I noticed that I wasn't in the editor. So
>>I called EDT again, and continued editing. I hadn't made any changes
>>yet, so I didn't notice that I was editing the same file on two
>>different machines, having mistakenly returned to a session on
>>another VAX where I happened to be in the same directory (on the
>>same, shared, disk, of course).
>>
>>It's obvious that this is undesirable behaviour. Shouldn't I get
>>something like `file currently locked by another user' or something?
>>Is this behaviour still there in newer VMS versions? Is there an
>>elegant way to prevent this undesired behaviour?
>>
>Its not in the least bit obvious. EDT only reads the original file, then
>closes it. Work is done in a temporary file, which is renamed to the output
>file name (usually next version of the original name) on write.
>Of all the systems I've worked on, I've never seen an editor that kept the
>original file locked as you wish. There are lots of legitimate needs to keep
>read access available to that original file.
READ access wouldn't be a problem; write access is the problem. Even if there
is some reason to have two processes have write access to the same file at
the same time, surely `whoever exits last wins' can't be the best strategy.
Phillip Helbig Tel. .............. +49 40 7252 4110
Hamburger Sternwarte Email .... phe...@hs.uni-hamburg.de
Gojenbergsweg 112 Fax ............... +49 40 7252 4198
D-21029 Hamburg Telex ............... 217884 hamst d
>------------------------------------------------------------------------------
>Bob Koehler |
>koe...@bessta.gsfc.nasa.gov | rkoe...@author.gsfc.nasa.gov
Bob Koehler
In article <430mh0$j...@rzsun02.rrz.uni-hamburg.de>, Phillip Helbig <phe...@hs.uni-hamburg.de> writes:
>In <42pj3o$6...@post.gsfc.nasa.gov> koe...@bessta.gsfc.nasa.gov (Bob Koehler) writes:
>
>
>>In article <42ora6$3...@rzsun02.rrz.uni-hamburg.de>, Phillip Helbig <phe...@hs.uni-hamburg.de> writes:
>>>By accident I was editing a file with EDT on a VAX (VMS 5.5-2) and
>>>when I returned to what I thought was the same session after checking
>>>email on another machine, I noticed that I wasn't in the editor. So
>>>I called EDT again, and continued editing. I hadn't made any changes
>>>yet, so I didn't notice that I was editing the same file on two
>>>different machines, having mistakenly returned to a session on
>>>another VAX where I happened to be in the same directory (on the
>>>same, shared, disk, of course).
>>>
>>>It's obvious that this is undesirable behaviour. Shouldn't I get
>>>something like `file currently locked by another user' or something?
>>>Is this behaviour still there in newer VMS versions? Is there an
>>>elegant way to prevent this undesired behaviour?
>>>
>
>>Its not in the least bit obvious. EDT only reads the original file, then
>>closes it. Work is done in a temporary file, which is renamed to the output
>>file name (usually next version of the original name) on write.
>
>>Of all the systems I've worked on, I've never seen an editor that kept the
>>original file locked as you wish. There are lots of legitimate needs to keep
>>read access available to that original file.
>
>
>READ access wouldn't be a problem; write access is the problem. Even if there
>is some reason to have two processes have write access to the same file at
>the same time, surely `whoever exits last wins' can't be the best strategy.
>
But they don't have write access to the same file. They have write access to
two physically different files, each with as different temporary entry, each
becomming a different version number. "whoever exits last wins" is the model,
whether they're editing, or copying, or creating the file in some other manner.
fair...@slc.slac.stanford.edu
> In article <430mh0$j...@rzsun02.rrz.uni-hamburg.de>,
Phillip Helbig <phe...@hs.uni-hamburg.de> writes:
>>READ access wouldn't be a problem; write access is the problem. Even if there
>>is some reason to have two processes have write access to the same file at
>>the same time, surely `whoever exits last wins' can't be the best strategy.
>>
>
> But they don't have write access to the same file. They have write access to
> two physically different files, each with as different temporary entry, each
> becomming a different version number. "whoever exits last wins" is the model,
> whether they're editing, or copying, or creating the file in some other
> manner.
And...if more than one person has write access to a directory,
for instance doing joint software development, then you should be
using CMS (or some other code management system) to keep track of
updates and supply a "reserve" function during edits. Neither the
editor, nor the file system (RMS), is the place for that
functionallity.
-Ken
--
Kenneth H. Fairfield | Internet: Fair...@Slac.Stanford.Edu
SLAC, P.O.Box 4349, MS 46 | DECnet: 45537::FAIRFIELD (45537=SLACVX)
Stanford, CA 94309 | Voice: 415-926-2924 FAX: 415-926-3515
-------------------------------------------------------------------------
These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
John E. Davis
: Of all the systems I've worked on, I've never seen an editor that kept the
: original file locked as you wish. There are lots of legitimate needs to keep
: read access available to that original file.
If everyone editing the file were using the same editor, the editor could
implement some sort of locking protocol, e.g., by keeping the names of all
files as well as who is editing the file, process id, etc.... in another
file. In the original poster's case something like this would probably
work since I assume he would use the same editor.
--John
Carl J Lydick
=If everyone editing the file were using the same editor, the editor could
=implement some sort of locking protocol, e.g., by keeping the names of all
=files as well as who is editing the file, process id, etc.... in another
=file. In the original poster's case something like this would probably
=work since I assume he would use the same editor.
Actually, if he were using EDT instead of TPU, it would be easy to modify the
procedure EVE_GET_FILE to spawn a DCL process if necessary, and have that
process open the file for exclusive access. When you exit from EVE, the
process is killed, and the files are closed, making them available to others.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CA...@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My
understanding of astronomy is purely at the amateur level (or below). So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it. If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.