[Info-vax] Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT)

[VAXman- at SendSpamHere.ORG]

In article <nkrceu$9bt$2 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-27 15:35, Bob Koehler wrote:
>> In article <nkr5cb$lui$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>> On 2016-06-24 14:52, Bob Koehler wrote:
>>>> In article <nkhf9i$7s3$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>>>
>>>>> Uh? Say what? Everything in TCP/IP is just a stream of bytes. There are
>>>>> no blocks, nothing is sent in any multiple of blocks.
>>>>> (And besides, text files in Unix do not have CF and LF in them. They
>>>>> just have LF. Which is why I was complaining about Unix ftp
>>>>> implementations, which often lies about file size, and sometimes cheat
>>>>> when transferring in text mode. These protocols were not designed by
>>>>> Unix people...)
>>>>
>>>>    So hwo does UNIX solve it?  By lieing about it?  Does that work
>>>>    anyhow?  If so, then why can't VMS lie about it?  Or do both UNIX
>>>>    and VMS have to read the file twice to get it right?
>>>
>>> With HTTP Unix just stat() the file, and return the size as reported,
>>> and everything is correct.
>>
>>    Not if the protocol is depending on CRLF.
>
>Well, I suspect you mean if Unix have a file in the native text format, 
>and is expected to serve it as a text with CRLF line endings. In that 
>case yeah, then stat() will not suffice.

What do you do in that case?  And, one could argue that the <LF> is akin
the VMS record's metadata.  Now, if you're adding the <CR><LF> (2 bytes)
you might have your file size if the file is VMS variable length. ;)   

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.