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

[Johnny Billquist]

On 2016-06-27 22:20, VAXman- at SendSpamHere.ORG wrote:
> 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:
>>>>> 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)?

I obviously do not have the answer to that one either, but the number is 
equally meaningless no matter who wrote the code.

> [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.

Bonus point for the Python reference.

>> 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.

No it is not the number of bytes written in the file. As noted before, 
the number of bytes written in the file can either be 1) The actual 
number of bytes written in the file, which should then exclude padding 
bytes at record ends, and padding bytes at block ends, or 2) the number 
of bytes constituting the blocks written, since in the end, all writes 
are in blocks.

This (your) number is neither.

> 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.

Totally agree that indexed and relative files make no sense in this 
context, so I'm leaving them out of it.

But the problem with the number (and code) above, is that it's not 
really a number that relates to anything relevant at all.

	Johnny