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

[VAXman- at SendSpamHere.ORG]

In article <nks2sl$4ce$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-27 22:28, VAXman- at SendSpamHere.ORG wrote:
>> In article <nkrqqm$fpl$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>> On 2016-06-27 19:40, Bob Koehler wrote:
>>>> In article <00B0B3EA.9F7943FA at SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
>>>>>
>>>>> OK... So we should all toss fixed, VFC, VAR, STM and STMCF formats and use
>>>>> STMLF exclusively.
>>>>>
>>>>> Again, the filesize (in bytes) CAN be had but they'll not mean what you want
>>>>> them to mean to your protocol transfer.  Again, I don't see that as any VMS
>>>>> problem;  I see it as a protocol limitation imposed by all of the *ixers out
>>>>> there that have, parochially, defined these protocols RFCs.
>>>>
>>>>    Hm.   Windows stores text lines with CRLF separators, so that's 2
>>>>    bytes meta-data per line of text.
>>>
>>> Well, with Windows it is not meta data, in that sense. It is actual file
>>> content.
>>>
>>>>  VAR stores text with leaing
>>>>    lengths in 16 bit words, so that's 2 bytes meta-data per line of
>>>>    text.
>>>>
>>>>    Would seem to me that VAR isn't even a problem.  When you do the
>>>>    conversion to the protocol's CRLF separators, you get the same total
>>>>    bytes.
>>>
>>> If it was only that simple... But of course, it is not... :-)
>>> With VAR files, if your record length is odd, it will be padded to an
>>> even number before the next record starts, meaning you have one
>>> additional byte not accounted for.
>>> If you then also select that records should not span blocks, you might
>>> actually get a lot of padding at the end of a block, which you normally
>>> do not see or notice.
>>> But doing the actual size calculations based on what meta data RMS is
>>> storing is just not possible. :-(
>>
>> Correct.  Records in VAR format files are padded is the length of the record
>> is odd to put the counter at a word aligned boundary.  In this case, the size
>> computed with the computation I specified (that'd make C$STD_STAT() incorrect
>> as well) could be off.
>
>Yes! Finally we agree (I hope). The current stored data cannot be used 
>to compute the size in bytes. The only way right now is to actually read 
>the file.
>
>Like I said, the code you showed for the C$STD_STAT() is equally useless.

But it IS the file size; it's not the recorded data size.  You DON'T WANT the
file size -- which the computation provides; you want the recorded data size
-- which that computation does not necessarily provide you.

In general, your desire provides nothing that'll make VMS work any better, so
why does or should VMS have to maintain it.  *ix doesn't either because it's
counting the <LF>.

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

I speak to machines with the voice of humanity.