[Info-vax] wrong file format

[Bill Gunshannon]

On 12/30/20 7:59 AM, Dirk Munk wrote:
> Jan-Erik Söderholm wrote:
>> Den 2020-12-29 kl. 23:05, skrev Dirk Munk:
>>> Bill Gunshannon wrote:
>>>> On 12/29/20 9:21 AM, Jan-Erik Söderholm wrote:
>>>>> Den 2020-12-29 kl. 14:35, skrev Phillip Helbig (undress to reply):
>>>>>> In article <rsfarr$smk$1 at dont-email.me>, Dirk Munk <munk at home.nl>
>>>>>> writes:
>>>>>>
>>>>>>>> I tried for about 45 minutes---all the suggestions posted here! 
>>>>>>>> It was
>>>>>>>> about 100 MB, so not all were quick to check.
>>>>>>>>
>>>>>>>> In the end, I managed to transfer it again (don't ask!) and 
>>>>>>>> somehow,
>>>>>>>> magically, it was OK.
>>>>>>>>
>>>>>>> I've dealt with problems like these before, usually caused by
>>>>>>> applications that were not written for VMS.
>>>>>>>
>>>>>>> You need to have a bit of a feeling for the different file types 
>>>>>>> of VMS
>>>>>>> to fix these problems, but if you have that, it's very simple to 
>>>>>>> solve
>>>>>>> these little puzzles.
>>>>>>
>>>>>> I don't know how many times I've used SET FILE/ATTR or CONVERT or 
>>>>>> TECO
>>>>>> to fix things like this.  I can usually look at the contents, look at
>>>>>> DIR/FULL, and see what needs to be done if they don't match, but this
>>>>>> was somehow different.
>>>>>>
>>>>>
>>>>> Nice that it was fixed! And no, I do not belive in magic... :-)
>>>>
>>>>
>>>> And, just so people don't think, based on earlier comments, that
>>>> Unix is somehow immune, I frequently have to remove "^M" characters
>>>> from text files on Unix. Unix's only saving grace in this regard is
>>>> that the solution is trivial.  :-)
>>>>
>>>> bill
>>>>
>>> No, of course Unix is not immune. Using <lf> or <cr> (Windows) as 
>>> record terminator is a rather silly idea. It means that you can't use 
>>> those characters in a record, and you have to scan the contents of a 
>>> file for those characters. Simply writing the length of a record at 
>>> the beginning of that record is far better solution.
>>
>> Having a <LF> or a <CR> in text files seems rather logical to me.
>> What else, if you want either a line feed or a carriage return?
>>
>> But yes, there are other ways to specify and delimiting a "line of text",
>> if you have a system suporting that.
>>
>> Now, if that "record" is something else than a "line of text"...
>>
>>
> 
> 
> The problem is that in Unix and Windows land there is no difference 
> between the metadata of a file, and the actual contents of a file. The 
> metadata should define the file and the records in the file, that should 
> be completely separate from the actual data contents of the file.

Can't speak for Windows, but Unix has no meta-data. Unix has only one
file type, a stream of bytes.  Everything else is application layer.

> 
> Suppose I have a file with binary data, and one byte has the binary 
> (ascii) value of <lf>, then Unix will use it as a record separator, even 
> if it is in the middle of the actual data of that record.

Unix has no records. If you cat the file it will line break at the <lf>.
If you od -c the file it will identify the <lf> as just that.

> 
> Suppose you have a VMS file with fixed record size. That file has no 
> records separators what so ever, it is one long stream of data. VMS can 
> calculate where the records start and end in the file. Suppose it 
> consists out of sets of three records of 100 bytes that belong together. 
> Then you can change the attributes of that file to records of 300 bytes, 
> and in one read operation you will have all the data that belongs 
> together. I've actually used this in the past.

And that would be an application concept, not really an OS thing.

> 
> Suppose you want to print such a file, then VMS will send a <cr> and a 
> <lf> to the printer after each record. Simple.

VMS won't.  Whatever application actually prints it will.

> 
> The DEC software engineers understood very well why it is a bad idea to 
> mix up contents of a file with the structure of a file, and that's why 
> they did not use stream files as standard RMS files in applications. 
> They are just there for compatibly with Unix, Windows etc.

And Unix made all files streams of bytes and lets the applications
decide what to do with them.  Not really an OS problem.

bill