#364 VMS Open Previous DB file error

release
closed-fixed
Eddy De Greef
Program (402)
5
2004-06-28
2004-04-11
Anonymous
No

In order to get this to run properly under VMS, In
menu.c, the following changes were added to
WriteNEditDB and ReadNEditDB respectfully ( diff -u
output ) -- see uploaded file.
roymac1@ntlworld.com

Discussion

  • diff -u menu.c menuFixed.c

     
    Attachments
  • roymac
    roymac
    2004-04-11

    Logged In: YES
    user_id=1018804

    It should also be noted that this has not been tested with a
    Unix platform - only VMS 7.3

     
  • Eddy De Greef
    Eddy De Greef
    2004-06-23

    • labels: --> Program
    • milestone: --> release
     
  • Eddy De Greef
    Eddy De Greef
    2004-06-23

    Logged In: YES
    user_id=73597

    Your fix for writing the history file appears flawed to me.
    When a file is opened in "r+" mode and the new contents is
    shorter than the old one, there will be some trailing
    garbage in the file when it is closed. At least, that's what
    happens on Unix.

    For instance, suppose that the history file contains this line:
    my.initial.history.entry

    If you reopen the file in r+ mode, and insert a new entry
    like this
    one:
    my.next.history.entry

    the net result will be a file containing this:
    my.next.history.entry
    ry

    Isn't there a way to force file truncation on VMS?
    Would "w+" work?

     
  • roymac
    roymac
    2004-06-23

    Logged In: YES
    user_id=1018804

    The conditional compilation statements should ensure that
    this fix is not used under unix - it should appear unchanged
    under unix, however, this was not tested. It would be no
    surprise if the "r+" did not work under unix.

    The code has been used daily since the fix - successfully.

    The following from the DEC C run-time library manual for
    OpenVMS might be useful:
    "r+" opens an existing file for read update access. It is
    opened for reading, positioned first at the beginning-of-file,
    but writing is also allowed.
    See fopen:
    http://h71000.www7.hp.com/doc/732FINAL/5763/5763pro_03
    0.html#index_x_855

    Contrast this with:
    r+ open text file for update (reading and writing)
    from:
    Tru64 UNIX Compaq C Language Reference Manual
    http://h30097.www3.hp.com/dtk/Compaq_C_Compiler/doc/lrm
    /DOCU0024.HTM#index_x_1134

     
  • Eddy De Greef
    Eddy De Greef
    2004-06-24

    Logged In: YES
    user_id=73597

    It's not the behaviour on Unix that I'm afraid of; I know
    it's compiled conditionally. Unix positions the file point
    at the beginning also, BTW.

    What I'm saying is that if the behaviour on VMS is the same
    as on Unix, the file is not truncated, and this can result
    in trailing garbage. This trailing garbage can eventually
    show up as junk entries in the Open Previous menu (which you
    may never have noticed, if they ever showed up at all).

    VMS appears to have ftruncate(), so we can use that to force
    truncation. So I would write the VMS part as follows:

    if ((fp = fopen(fullName, "w")) == NULL)
    #ifdef VMS
    {
    if ((fp = fopen(fullName, "r+")) == NULL)
    return;
    if (ftruncate(fullName, 0) != 0)
    return;
    }
    #endif

    Do you see any problem with that?

     
  • Eddy De Greef
    Eddy De Greef
    2004-06-28

    • assigned_to: nobody --> edg
    • status: open --> closed-fixed
     
  • Eddy De Greef
    Eddy De Greef
    2004-06-28

    Logged In: YES
    user_id=73597

    Summary of private communication with roymac:
    he confirmed that his suggested fix resulted in trailing
    garbage in the history file, as I suspected. Adding an
    ftruncate() call solved the problem. The fix is now in CVS.