Re: Another huge bug: DECwindows MAIL: include file

From: David Froble (davef_at_tsoft-inc.com)
Date: 10/05/03

  • Next message: John Gemignani, Jr.: "Re: RMS provide API to directory files?" 
    Date: Sun, 05 Oct 2003 00:20:53 -0400

    JF Mezei wrote:

    > Mike Naime wrote:
    >
    >>File Locking is an OS level security feature. For someone who claims to
    >>know VMS, you should know this ***! It does not matter if you are in mail
    >>or at the OS level.
    >>
    >
    > So you agree then that if at the OS level, the lock allows one to read the
    > file, as demonstrated by the ability to TYPE the file, then any application
    > should be able to read the file ?

    Here's the logic flaw. 'Should be able to read' and 'should read' are two
    entirely seperate issues. In the first case, if the log file is opened ACCESS
    WRITE ALLOW READ they the ability to open the file for reading is there. Note
    that usually two processes cannot both open a sequential file for ALLOW WRITE,
    and that there is a difference between ALLOW WRITE and ALLOW MODIFY.

    >>file is not closed. The file is Open and Writelocked by another process for
    >>good reason.
    >>
    >
    > Mail isn't trying to write to the file. It just wants to read it. (unless
    > there are some really heavy duty stuff done by an include that goes so much
    > beyond what TYPE needs to do)
    >
    >
    >>So, If I cannot copy a file at the OS level, Why should I be able to make a
    >>copy in mail? BUG?? I think not.
    >>
    >
    > But if I can TYPE the file, and I can OPEN/READ/SHARE temp <log file>, then it
    > means that the process who controls the writing to the file has allowed
    > readers to the file. It is only because poorly written applications attempt to
    > take a greater-than-necessary lock on the file that it fails.
    >
    > I can understand COPY failing because Copy is expected to also handle indexed
    > files, and you don't want to copy an index file while folks are writing to it
    > since the copy may take a snapshot of the index at the wrong time resulting in
    > corruption in the new copy.
    >
    > And I can understand EDT failing since it does not read the whole file
    > sequentially, it only reads a portion that you need. However, TPU has no
    > problem reading log files.
    >
    > But if it is safe to TYPE the file, if it is safe for TPU to read the file,
    > why should MAIL be prohibited from reading a file to include it ? In all these
    > cases, the operation acesses only the data/text portion of the file and the
    > index (if any) itself isn't included.

    It's not necessarily SAFE to TYPE the file. TYPE will show what's been written
    to the file, but doesn't assure that nothing else will be written to the file.

    >>This is the only way to look at a Writelocked Open file without closing it.
    >>Gee, Even you seem to know that! :-)
    >>
    >
    > TYPE is not the only way. DCL can be used ( OPEN/READ/SHARE ), so can TPU.
    > And I suspect any C program that uses fopen to read the file.

    It's RMS that uses the DLM. Any I/O at a lower level can choose to ignore the DLM.

    > If, as you propose, the VMS locking system is doing its job by preventing MAIL
    > from reading the file, this would suggest that VMS is failing to prevent TYPE
    > from displaying the contents.
    >
    > If TYPE is allowed to display the contents, this would mean to me that the
    > process writing to the file has allowed read operations to occur. So it is
    > just a matter of applications such as MAIL to open their files for reading
    > with the proper flags set to ensure that they can access those files which are
    > opened but for which reading is allowed.
    >
    > my complaint still stands: DECW$MAIL should open files for include with the
    > right flags to enable it to include log files.

    If the design of DECW$MAIL is to only send complete files that are included,
    then I'd disagree with this statement. What you're discussing is an
    implementation decision. You may not like the decision, but it's certainly NOT
    a bug.

    A bug is when something is documented to perform in a specific manner, and it
    does not perform in that manner.

    Dave 

    -- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      Fax: 724-529-0596
DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com
170 Grimplin Road
Vanderbilt, PA  15486
  • Next message: John Gemignani, Jr.: "Re: RMS provide API to directory files?"
    Loading