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

[VAXman- at SendSpamHere.ORG]

In article <nkgspt$rm$2 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-23 14:36, VAXman- at SendSpamHere.ORG wrote:
>> 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?
>
>This whole thread came about because some people pointed out that exact 
>file sizes, to the byte, sometimes were wanted. And then it's been a 
>thread of "why?". And when I give an example of why, it becomes a thread 
>of "why?".
>
>Yes, I know VMS couldn't care less. RSX also couldn't care less. Me, 
>writing an http server (as well as an ftp server), do care. And doing 
>these things, which many people consider to be pretty basic tools that 
>all systems should have, is a pain because the file system do not have 
>this information.
>
>Yes, there are solutions. They are costly. Could there possibly be a 
>point in adding this information, if it can be done at a low cost?
>
>You are just putting your head in the sand and saying that since it's 
>not there, we don't need it.

Why pay for it when you don't need it?  Pay for it when you do!

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

I speak to machines with the voice of humanity.