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

[Johnny Billquist]

On 2016-06-27 18:56, VAXman- at SendSpamHere.ORG wrote:
> 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.

I want/need the file size in bytes in VMS if I am implementing some 
protocols. I know that much. Why do you say I do not want it?
Are you basing that comment on your arbitrary and useless definition of 
file size in bytes? If so, then you are correct, I do not want your file 
size in bytes. I want the actual number of bytes I will get if I read 
the file from disk. That is the byte size I want and need.

What Unix systems sometimes do for text is that if the file, as 
indicated by stat() is big enough, the program just figures that it is 
going to be too costly to work out the size, and will instead send the 
content in chunked form. A bit less efficient, and you will not get a 
progress bar, but it's a tradeoff. But for non-text files, stst() in 
Unix will always give the right information.

	Johnny