180780 - Stream-lf, data corruption

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[King George, Bob's friend]

User-Agent:       Mozilla/4.75 [en] (X11; U; SunOS 5.8 sun4u)
Build Identifier: Mozilla/5.0 (X11; U; OpenVMS AlphaPC_264DP_500_MHz; en-US; rv:1.2b) Gecko/20021022

I do not know why the status of bug report 180192 was so quickly set to
"RESOLVED". This matter is not very pleasant, it is quite embarrassing for
OpenVMS. Nevertheless, it is not resolved. Therefore I file a new bug
report and will continue to do so until we conclude that this issue is
solved. This matter is too serious to ignore it.

Stream_lf w/ crcc is no useful RMS information for binary files. A simple
example like copying such a file to the null device shows that this needs
to be fixed in Mozilla for OpenVMS.

Self-extracting archive files like the ECOs (patches) on Compaq's web site
for OpenVMS are affected the same way as any other binary file, including
ZIP files, and there are too many reports on comp.os.vms where people have
reported data loss and the corruption of the operating system because of
the wrong choice for the RMS information. Who is going to accept
responsibility ?

We cannot establish a policy that defines "useful" file types for OpenVMS
like self-extracting archive files or zip files (beside that I argue right
now they are not safe either), because a third party may decide to choose
another file type for good reasons, such as a PCSI file. Or a third party
may not care about OpenVMS at all, but OpenVMS users should still be able
to download files without the fear of data corruption.

Stream_lf is not useful for text files with CR as delimiter. Here we need
stream_cr instead.

We need a solution! We do get all information we need from the web server,
namely the file type (extension), the mime content type and the file
content itself. This is sufficient information to scan and analyze the file
and determine the proper record format, record attributes etc.. Whether
this is going to be fixed only in Mozilla for OpenVMS or based on an
OpenVMS system service does not matter, although a general solution would
be useful for a lot of other applications, too.

Early versions of Netscape 3 for OpenVMS were able to create some binary
files with fixed 512 byte record length and with no record attribute, such
as GIF, JPEG etc.. This feature was lost in the final "GOLD" release of
Netscape 3 for OpenVMS.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Colin Blake]

If you believe that bug 180192 needs re-opening, please do so. Opening yet
another bug report for the same problem just results in communication splatter.

But please, if you're going to re-open 180192, please bring some additional
information to the table, such as an idea for how the problem can be fixed.