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

[Johnny Billquist]

On 2016-06-27 23:29, VAXman- at SendSpamHere.ORG wrote:
> 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.

Well, what do you mean by file size then? The number this computation 
gives is neither the number of bytes used on the disk, nor the number of 
bytes I would get if I read the file.

The number is in fact just an approximation of the number of bytes I 
would get if I read the file.

Sometimes approximations can be acceptable, at which time this algorithm 
works, at other times approximations are not acceptable, in which case 
this number is useless.

Because, as I said, it don't really represent any real number that tells 
me anything about the file.

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

VMS do not work any better because it tracks the number of times a file 
have been modified either, and yet VMS do track that. Why should it, then?
Unix does give me a number I can use sometimes. The only time it is not 
usable is when I want to give something back in a network standard text 
format, and the file is in the Unix standard text format.
Which is already much better than what VMS does today. And if VMS now 
where to be improved here, why not make it better than Unix, instead of 
just using Unix as some reference?

	Johnny