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

[VAXman- at SendSpamHere.ORG]

In article <nkrbmt$7k8$2 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-23 23:40, VAXman- at SendSpamHere.ORG wrote:
>> In article <nkhf0u$71o$2 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>> On 2016-06-23 21:42, VAXman- at SendSpamHere.ORG wrote:
>>>> In article <nkhdao$2us$3 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>>> On 2016-06-23 21:23, VAXman- at SendSpamHere.ORG wrote:
>>>>>> In article <nkhcik$1o0$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>>>>> On 2016-06-23 20:46, David Froble wrote:
>>>>>>>> Johnny Billquist wrote:
>>>>>>>>> On 2016-06-23 18:06, VAXman- at SendSpamHere.ORG wrote:
>>>>>>>>>> In article <nkgspt$rm$2 at Iltempo.Update.UU.SE>, Johnny Billquist
>>>>>>>>>> <bqt at softjar.se> writes:
>>>>>>>>>>> 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!
>>>>>>>>>
>>>>>>>>> Which, for a web server, is every time a document is requested, which
>>>>>>>>> might mean a dozen requests for a single page. And that is just one
>>>>>>>>> example. And for a 10M document, calculating the size every time is
>>>>>>>>> pretty costly... Reading through 10M to find the size, and then read
>>>>>>>>> through it again, to deliver it. Color me not-excited.
>>>>>>>>>
>>>>>>>>>     Johnny
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why would you read through it twice?  With a few exceptions, read it
>>>>>>>> into memory, then transmit it.  Something you got to do anyway.  Perhaps
>>>>>>>> just re-ordering the task.
>>>>>>>>
>>>>>>>> Too big?  Got to ask, what's wrong with doing things in segments?  Maybe
>>>>>>>> not how the *ix world does things.  Who's to say they are always right?
>>>>>>>
>>>>>>> I think you missed the point. For a web server, you *have* to give the
>>>>>>> size before you start sending data. Doing it in segments then obviously
>>>>>>> is not the answer. Nor is reordering of anything. Size comes first, data
>>>>>>> comes after. Do I have to repeat it again?
>>>>>>>
>>>>>>> And blaming Unix isn't useful/meaningful either. The protocol is that
>>>>>>> way. Deal with it.
>>>>>>> And yes, it can be too big to just gob into memory, not to mention that
>>>>>>> gobbing many megs of memory for this is a pretty poor design.
>>>>>>
>>>>>> OK.  So your web server sits on VMS.  If the file is NOT RFM=STM, call the
>>>>>> callable CONV$ert routine and convert it to RFM=STM.  There, done once and
>>>>>> then no more!  Now, you can have your precious byte-counted file size from
>>>>>> <end_of_file_block-1>*512 + <end_of_file_byte>.  Both values easily gotten
>>>>>> and the math is simple enough that even Bernie *should* be able do it.
>>>>>
>>>>> Apart from the fact that it's reusable, what you just did was read the
>>>>> file twice, to serve it.
>>>>
>>>> OK.  But only done once.
>>>
>>> Assuming you then keep track of this converted file, it does not change,
>>> and you have the storage, yes...
>>
>> Why would it change?
>
>Because nothing is set in stone? People use the system, people change 
>content, people transfer files, people do all kind of strange things...
>Imagine...
>
>>>>> And now you are creating alternative files for requested files, and need
>>>>> to keep track which ones you have created an alternative for, and
>>>>> substitute one for the other for those cases. I can see how this can
>>>>> become rather exciting over time...
>>>>
>>>> Overwrite the existing.  It's text and VMS can read it because it'll see the
>>>> record format.
>>>
>>> Whoa! I don't know about you, but personally I would be extremely pissed
>>> if a tool that is supposed to only read my file were to modify it. Even
>>> if the contents supposedly should appear to look the same afterwards.
>>>
>>> But you're even making some pretty horrible assumptions here. Assuming
>>> that the file even is a text file to start with, for which conversion to
>>> a stream, might be assuming too much.
>>
>> If it's not text, then what does it matter?  Binary?
>
>So you have a sequential file with variable size records, and no file 
>attributes. How do you find the size?

Why would the file attributes matter?

file_size_in_bytes = <end_of_file_block-1>*512 + <end of file byte>

... but it won't mean what you want it to mean.  

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

I speak to machines with the voice of humanity.