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

[VAXman- at SendSpamHere.ORG]

In article <nkgd41$2g9$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-21 19:07, VAXman- at SendSpamHere.ORG wrote:
>> In article <nkbpti$i3$1 at news.albasani.net>, Jan-Erik Soderholm <jan-erik.soderholm at telia.com> writes:
>>> Den 2016-06-21 kl. 18:18, skrev VAXman- at SendSpamHere.ORG:
>>>> In article <nkbn1q$5cn$2 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>>> On 2016-06-19 04:35, David Froble wrote:
>>>>>> Jan-Erik Soderholm wrote:
>>>>>
>>>>>>> Yes, but that is a simple calculation with 1 block = 512 bytes.
>>>>>>> It does not correctly display partially filled blocks. I guess
>>>>>>> that what most here are talking about is the size up to the
>>>>>>> marker. Convering the used/allocated number of blocks is simple.
>>>>>>>
>>>>>>> Jan-Erik.
>>>>>>
>>>>>> I would suggest "what does it matter?"
>>>>>>
>>>>>> It's not like some other file is going to use the unused portion of some
>>>>>> disk block, or, as suggested, unused part of 4096 bytes ....
>>>>>
>>>>> No. But if you implement FTP, or a web server, or any number of other
>>>>> tools/programs, they are expected to report file sizes in bytes, and the
>>>>> byte count should be *accurate*. Even one byte off is not acceptable.
>>>>
>>>
>>> A web server probably always has to calculate the number of bytes
>>> sent to get it right. There is many ways that the sent data can be
>>> different then the on-file data and the web page can be "dynamic".
>>>
>>>> Why?
>>>
>>> In HTTP you can end up with connections staying open and
>>> waiting for that final byte that never comes.
>>
>> Exactly!  And you answered the 'Why?' prior to the quoted first instance.
>
>I don't get your point. I'm saying that the reported file size has to be 
>correct to the byte, and we're talking about data bytes here. Actual 
>content. Calculating a file size based on blocks totally do not cut it, 
>as that will include meta-data, and will possibly exclude actual data, 
>so the size will not be accurate.
>
>And I pointed out that it has to be accurate, since the protocols says 
>so, and programs work under this assumption.
>
>So what did you mean with that comment?


It's important to that protocol or others, but not to VMS.  The sizes reported on VMS
are concerned only with storage consumption.  That size may or may not reflect what is
seen when VMS presents that data to you.  In your protocol(s), it may be important to
count a <CR> and or <LF> that's sent if the data is text based.  Those <CR>s and <LF>s
don't necessarily have to exist in the on disk stored file.  You could, for example,
$ TYPE out an indexed file and get/see text representation of all of its records.  On
the disk, there's more than that -- for keyed access to the records -- that you'll not
see in the output.  In addition, those records are, more likely than not, compressed;
therefore, all that is seen if you $ TYPE that file does NOT necessarily exist within
the data stored on the storage device.

So, if your protocol needs an exact size, then you'd better count it.  If VMS doesn't
need it -- and I just outlined why it doesn't have it -- then why should it have to
provide it? 
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.