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

[VAXman- at SendSpamHere.ORG]

In article <nkro7d$8k2$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-27 18:55, VAXman- at SendSpamHere.ORG wrote:
>> In article <nkrhao$lkq$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>> On 2016-06-27 17:19, VAXman- at SendSpamHere.ORG wrote:
>>>> 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:
>>>>>>>>> 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?
>>>
>>> If you get a request for a file, it matters greatly if it has implied
>>> CRLF or not. If it does, you should add an explicit CR+LF at each record
>>> end, when sending the file. If it does not have this attribute, you
>>> should definitely not add a CR+LF at each record end.
>>
>> That'so not a file attribute.
>
>Ok. So I should have said record attribute. My mistake.
>
>>> I did not expect I should have to explain such basic things to you. Were
>>> you really serious with this question?
>>>
>>>> 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.
>>>
>>> That number is certainly a number. It is not a number I ever expect
>>> anyone would find useful for anything, so why do you even bring it up?
>>
>> Because it's THE file size.
>
>No it is not. It's an arbitrary number you decided to calculate.
>Why would that be any more valid than just <end-of-file-block>*512. Why 
>do you care about the first free byte information at the end if you 
>don't care about the free bytes in other records?

Why does DEC C (DEC, Compaq, HP, VSI)?  

[King Arthur] Consult the Book of VMS Source Listings. 
[Brother Maynard] C$STD_STAT, chapter two, verses nine through twenty-one. 
[Cleric]

     if (recattr.fat$l_efblk != 0) {
         stat_buf->st_size = ((off64_t)recattr.fat$w_efblkh * 65536
                            + (off64_t)recattr.fat$w_efblkl - 1 ) * RMS_BLOCKSIZE
                            + recattr.fat$w_ffbyte;
     }
     else {
         stat_buf->st_size = ((off64_t)recattr.fat$w_hiblkh * 65536
                            + (off64_t)recattr.fat$w_hiblkl ) * RMS_BLOCKSIZE
                            + recattr.fat$w_ffbyte;
     }

[Brother Maynard] Amen.

 
>And why just calculating based on the end-of-file-block and not 
>allocated blocks?

The calculation is the bytes written in the file.  Allocated blocks you would
not be outputting in your HTTP connection UNLESS they were written to by some
application.

The file size is, primarily, only relative to the size of the file if it is a
sequential file.  RELATIVE and, most definitely, INDEXED files mailtain data
that is only for the specialize access each provides (metadata).  INDEXED can
have data in the records and keys compressed; thus, all bets are off on using
the file size.

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

I speak to machines with the voice of humanity.