[#10] Complex path related issue
Summary Complex path related issue
Queue Vim on VMS
Type Bug
State Accepted
Priority 2. Medium
Requester Zoltan Arpadffy <zoli (at) polarhome (dot) com>
Created 12/03/2010 (2489 days ago)
Updated 12/29/2010 (2463 days ago)

12/29/2010 sferencik@alpha.polarhome.com Comment #3 Reply to this comment
I suppose the solution could be one of (or a combination of) the following:

1) Opening the file

It should be configurable whether, when editing testdir:TESTFILE.TXT, the file
is opened as
or as

I personally would configure this to be always the latter (physical path), but
perhaps someone would go for the former.

Perhaps this should be a VMS-only feature of vim.

It should also be possible to change this setting per file. For example, I may
want to open all files using the physical path, except of FOO.TXT, 
where I want
to use the logical path. I should be able to define an autocommand
(BufReadPre FOO.TXT) that switches the setting to "logical" when opening

(As described in comment #2, vim does not allow a BufReadPre autocommand to
change the name of the file to be edited. I think that is a good security
policy, and can be retained. This setting allows one kind of hole into this
policy, but the hole is very reasonable and limited, so it should not 
present a
security problem.)

2) Writing the file

Again, it should be configurable, when the file is opened as
i.e. using a logical path, how the writing behaves. I see 2 options:

a) Copy to the first path to which testdir translates.

    As Zoltan described, this is how vim behaves currently. I think this is not
    functionally wrong, strictly speaking, but it can be annoying/surprising.

    In fact, this is similar to using VMS copy: when TESTFILE.TXT only 
exists in
    TEST_3, and we execute
     $ copy testdir:TESTFILE.TXT testdir:TESTFILE.TXT
    the file is copied to TEST_1.

b) Copy over the current file.

    I suppose this is what Zoltan wants. The file should be replaced in TEST_3.

    Again, this should be configurable as a setting (perhaps global), but
    modifiable with an autocommand (per file).

c) Copy over the first testdir:TESTFILE.TXT (?!).

    This is something to consider. For example, TESTFILE.TXT only exists in
    TEST_3. Zoltan opens it in vim. In the meantime, someone creates

    Is there any case when Zoltan may want to replace the file in TEST_2?

    Perhaps not. If not, we should not consider c) an option.

    In the very least, we must consider this scenario in b): the implementation
    of b) cannot be simply to find the first occurrence of testdir:TESTFILE.TXT
    and replace it. It is wrong to assume that the first testdir:TESTFILE.TXT
    found when writing is the same as the first testdir:TESTFILE.TXT found when

Note: at work, we use multi-translation logicals like testdir. The first
    translation refers to a user directory, the latter to a system directory.
    (Is this common elsewhere?) The system directory is not writable.

    Thus, to continue the example above, if my setting was to use b)-style
    writing (replace the file), and I edit and write a file in the system
    directory, the write will fail.

    But this can be solved by the user:
    - detect that the file is opened read-only -> change to a)
    - try writing b)-style, try/catch e45 or e212 -> change to a)

12/06/2010 sferencik@alpha.polarhome.com Comment #2 Reply to this comment
This is really an issue; I will try to describe how I am dealing with it:

The natural workaround (from my point of view) was to introduce a BufReadPre
auto-command, which would expand the path:

1) :edit testdir:TESTFILE.TXT
2) the BufReadPre autocommand kicks in, notices that the filename uses 
a rooted
    logical name, and instead of opening
    it translates the logical and opens
3) the write then behaves as expected

Alas, this is not possible. An autocommand is not allowed (by vim) to change
the name of the file to be opened (security reasons).

Since the approach above did not work, I am now dealing with this with 
a BufRead
(i.e. BufReadPost) autocommand:

     if has('vms')
         autocmd BufRead,BufWritePost * nested call ReopenFileIfNecessary()

1) :edit testdir:TESTFILE.TXT
2) vim opens testdir:TESTFILE.TXT
3) as a post-read action, vim calls ReopenFileIfNecessary(), which 
detects that
    a rooted logical (testdir) is used in the name, calls
     system("write sys$output f$search(\"testdir:TESTFILE.TXT\")")
    to translate this to
    and then opens this file immediately.

The user doesn't even notice that testdir:TESTFILE.TXT was ever opened 
(the file
only flashes there for a split second). However, it is really opened, and it
stays in history. That is ugly: suppose I am past step 3, so I am editing file
to go back
to where I was in step 1. When I press Ctrl-O, I go back one step in history,
i.e. to testdir:TESTFILE.TXT, at which point ReopenFileIfNecessary() is called
and I "slide" back to step 3. (2Ctrl-O solves this, of course.)

Additionally, it is ugly because I am not really opening 
testdir:TESTFILE.TXT as

Is the desired behaviour clear? If I edit testdir:TESTFILE.TXT 
(suppose the name
of the file stays the same, i.e. I do NOT reopen the file using the physical
path), is it clear that using :write should write a new version of the file in

12/03/2010 Zoltan Arpadffy State ⇒ Accepted
Summary ⇒ Complex path related issue
12/03/2010 Zoltan Arpadffy Comment #1
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ Complex path related bug
Queue ⇒ Vim on VMS
Reply to this comment
Vim writes back the edited file into the first directory in the complex path.

For example:

TITAN2_ZAY $ cre/dir <.testdir.test_1>
TITAN2_ZAY $ cre/dir <.testdir.test_2>
TITAN2_ZAY $ cre/dir <.testdir.test_3>
TITAN2_ZAY $ sh def
TITAN2_ZAY $ def /nolog testdir 

TITAN2_ZAY $ sh log testdir

Create a file in the last directory of the complex path.

TITAN2_ZAY $ dir testdir


TESTFILE.TXT;1                                  1   3-DEC-2010 15:03:25.38

Total of 1 file, 1 block.



TESTFILE.TXT;1                                  1   3-DEC-2010 15:03:25.38

Total of 1 file, 1 block.

Edit file testdir:TESTFILE.TXT and save.
The result is that Vim writes to the first directory of the complex 
path and not to the directory where the original file is found.



TESTFILE.TXT;1                                  1   3-DEC-2010 15:05:16.83

Total of 1 file, 1 block.


TESTFILE.TXT;1                                  1   3-DEC-2010 15:03:25.38

Total of 1 file, 1 block.

Grand total of 2 directories, 2 files, 2 blocks.

     1   111
     1   222111

Number of difference sections found: 1
Number of difference records found: 1