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

[VAXman- at SendSpamHere.ORG]

In article <nkrhga$lkq$2 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-27 17:23, VAXman- at SendSpamHere.ORG wrote:
>> 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. ;)
>
>In a Unix system? You will have to read the file to figure out what the 
>size is. There is no other way.
>
>Not that you often hit that situation, as most larger files transferred 
>will not be in a native Unix text format, and be required to be 
>translated into the network standard text format (which is not the same 
>as the Unix format).
>
>How much do you really want to go into how and what Unix does, and how 
>network protocols work here? Isn't this rather irrelevant to the 
>question of getting a file size in bytes in VMS?

Absolutely!  But you don't want the file size in bytes on VMS.

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

I speak to machines with the voice of humanity.