179559 - Library names, RMS record information, general file I/O

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[King George, Bob's friend]

User-Agent:       Mozilla/5.0 (X11; U; OpenVMS AlphaPC_264DP_500_MHz; en-US; rv:1.2b) Gecko/20021022
Build Identifier: Mozilla/5.0 (X11; U; OpenVMS AlphaPC_264DP_500_MHz; en-US; rv:1.2b) Gecko/20021022

1. The shared library names used in Mozilla for OpenVMS do not comply with the
OpenVMS standard. OpenVMS uses the scheme, XXX$YYY_SHR.EXE, whereby XXX is the
project name (here MOZILLA), YYY describes the purpose of the principal task of
the library, "_SHR" is used to indicate that it is a shared library (typically
in located in SYS$SHARE: ) and .EXE is the file extension used for executables
and shared libraries. Mozilla for OpenVMS uses LIBYYY.SO. OpenVMS is not UNIX!
Mozilla for other operating systems uses the native schemes, e.g. Mozilla for
MS-Windows uses the MS-Windows scheme.

2. OpenVMS file I/O is based on RMS. Essential information about every file is
provided in the form of file, record and RMS attributes. Wrong information will
result in data corruption.

Mozilla for OpenVMS shared libraries and other binary files are installed with
Record format:      Stream_LF, maximum 0 bytes, longest 0 bytes
Record attributes:  Carriage return carriage control

`Stream_LF' indicates that every record ends with an LF, an impossibility if the
binary file contains no LF or if no LF's are found a 32 Kibyte block (an RMS
limitation). `Fixed length 512 byte records' would be the right choice for
shared libraries.

`Carriage return carriage control' implies that after the transfer of every
record the application needs to add a carriage return carriage control (depends
on the device, e.g. printer w/ LF or CR-LF control). The use of this particular
attribute makes no sense for plain binary files. `None' would be the right
choice for shared libraries.

Compare with the transfer of a binary file via FTP in ASCII mode !

A small test shows how critical the situation is:

$ COPY SYS$COMMON:[MOZILLA]LIB*.SO NL:
%COPY-E-WRITEERR, error writing NL:[]LIBGTK.SO;1
-RMS-F-RSZ, invalid record size
%COPY-W-NOTCMPLT, SYS$COMMON:[MOZILLA]LIBGTK.SO;1 not completely copied
%COPY-E-WRITEERR, error writing NL:[]LIBXPCOM.SO;1
-RMS-F-RSZ, invalid record size
%COPY-W-NOTCMPLT, SYS$COMMON:[MOZILLA]LIBXPCOM.SO;1 not completely copied

NL: is the simple NULL device.

Any OpenVMS compliant application will fail the same way.

3. Mozilla for OpenVMS saves binary files from the web as Stream_LF/CRCC files.
Find reports about corrupted files due to this bug on the USENET, e.g.
comp.os.vms. This includes fatal system updates thanks to corrupted files.

For the record: THE SITUATION IS CRITICAL !


Reproducible: Always

Steps to Reproduce:
1. See details.
2.
3.

Actual Results:  
See details.

Expected Results:  
File I/O for OpenVMS needs to be adapted.

Comment 1

[hacker formerly known as [e-mail]]

OpenVMS -> colin

Comment 2

[Colin Blake]

1. shared library names used in Mozilla

The OpenVMS version of Mozilla is, as you know, a port of the UNIX version. This
explains why the file names follow the UNIX naming convention. Yes, I know you
don't like the fact that its a port, and I agree that it does make some aspects
of the user inferface different to native OpenVMS applications, but that's just
the way it is with a ported product. Java and Apache are other ported products
which are similar in this respect, and so Mozilla isn't unique.

2. record format and record type of shareables and executables

The shareables and executables being stream_lf is a result of how Mozilla is
currently being built. But the points you make are valid and I will make sure
that for all future releases (starting with 1.2 final) that the files are of
"Fixed length 512 byte records" format.

3. saving binary files

Again, this is due to the fact that its a port of the UNIX version, and in UNIX
there is only one file type; stream. In addition, when a file is downloaded from
a server, only the file contents are transferred; platform specific file
information (such as record format and record type for OpenVMS) are NOT
transferred. So the server doesn't give us the "file type" information, and the
browser doesn't expect it. I'm not sure what we can do to help this situation,
but if you can provide some real examples of "file corruption" (new bug report
please, see below), I'll gladly take a look and see if it can be prevented.

By the way, in the future please submit a separate bug report for each bug being
reported. It makes tracking the bugs a lot easier. Thanks.

Comment 3

[King George, Bob's friend]

Thank you for acknowledging item 2.