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

History
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
     testdir:TESTFILE.TXT
or as
     USRDSK:<ZAY.WORK.TESTDIR.TEST_3>TESTFILE.TXT

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
FOO.TXT.

(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
     testdir:TESTFILE.TXT
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
    TESTFILE.TXT in TEST_2.

    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
    opening.

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)
    or
    - 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
      testdir:TESTFILE.TXT
    it translates the logical and opens
      USRDSK:<ZAY.WORK.TESTDIR.TEST_3>TESTFILE.TXT
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()
     endif

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
     USRDSK:<ZAY.WORK.TESTDIR.TEST_3>TESTFILE.TXT
    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
USRDSK:<ZAY.WORK.TESTDIR.TEST_3>TESTFILE.TXT, and want to use Ctrl-O 
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
requested.

---
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
TEST_3?

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
   USRDSK:<ZAY.WORK>
TITAN2_ZAY $ def /nolog testdir 
USRDSK:<ZAY.WORK.testdir.test_1>,USRDSK:<ZAY.WORK.testdir.test_2>,USRDSK:<ZAY.WORK.testdir.test_3>

TITAN2_ZAY $ sh log testdir
    "TESTDIR" = "USRDSK:<ZAY.WORK.TESTDIR.TEST_1>" (LNM$PROCESS_TABLE)
         = "USRDSK:<ZAY.WORK.TESTDIR.TEST_2>"
         = "USRDSK:<ZAY.WORK.TESTDIR.TEST_3>"

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

TITAN2_ZAY $ dir testdir

Directory USRDSK:<ZAY.WORK.TESTDIR.TEST_3>

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

Total of 1 file, 1 block.

TITAN2_ZAY $ dir testdir:TESTFILE.TXT

Directory USRDSK:<ZAY.WORK.TESTDIR.TEST_3>

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.

TITAN2_ZAY $ dir testdir:TESTFILE.TXT

Directory USRDSK:<ZAY.WORK.TESTDIR.TEST_1>

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

Total of 1 file, 1 block.

Directory USRDSK:<ZAY.WORK.TESTDIR.TEST_3>

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.

TITAN2_ZAY $ diff USRDSK:<ZAY.WORK.TESTDIR.TEST_3>TESTFILE.TXT 
USRDSK:<ZAY.WORK.TESTDIR.TEST_1>TESTFILE.TXT
************
File USRDSK:<ZAY.WORK.TESTDIR.TEST_3>TESTFILE.TXT;1
     1   111
******
File USRDSK:<ZAY.WORK.TESTDIR.TEST_1>TESTFILE.TXT;1
     1   222111
************

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

DIFFERENCES /IGNORE=()/MERGED=1-
     USRDSK:<ZAY.WORK.TESTDIR.TEST_3>TESTFILE.TXT;1-
     USRDSK:<ZAY.WORK.TESTDIR.TEST_1>TESTFILE.TXT;1