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

[VAXman- at SendSpamHere.ORG]

In article <nl3qcs$d0h$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-30 19:00, VAXman- at SendSpamHere.ORG wrote:
>> In article <nl3ffj$ibt$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>
>>> [...]
>>>
>>> I'm not even sure what you are trying to say or prove anymore.
>>>
>>> Your LOGIN.CMD have 48 allocated blocks. That's the size your file take
>>> up on the disk. You might fight and deny it all you want. Won't change a
>>> thing. (And counting that in bytes is 24576 bytes. No more, and no less.)
>>>
>>> Furthermore, the number of byte actually in that file is something you
>>> cannot tell me without reading through the file. And with that "number
>>> of bytes", I am referring to the number of bytes you would read, if you
>>> were to do sequential $GET on the file until you get an EOF error, and
>>> you sum together the lengths of all the records $GET gave back to you.
>>
>> Where did I read through the file?  OK.  I did a SEARCH to show you what the
>> XAB$_FILE_LENGTH_HINT would give you without reading the file.
>
>Aha. Ok. I'll apologize. You did not read through the file for this. 
>Yes, this information actually exists, and in exactly the form that I 
>suggested a number of posts ago, which you dismissed as totally stupid 
>that you did not think VMS should do.

You didn't suggest it exists!

I thought it was stupid that a file's data recorded size should be shown for
the file size because it is not.  If you're trying to insult me for the EOF,
you're actually insulting the VMS Engineering group because that's what they
used for the C$stat().  If it was good enough for C coders, it must have been
correct. ;)



>Now, unfortunately, this information is only managed on ODS-5, so you 
>loose if you have ODS-2 (or ODS-1).

There are so many ODS-1 volumes today on VMS.  As for ODS-2, just convert the
volume to ODS-5.  It's not painful. ;)



>But anyway, that means that for the future, one would hope that a 
>stat-like system call for VMS would actually base the returned value on 
>what is recorded in this field instead, when available.

That would be a good suggestion for those C-ing their way to fame and fortune.



>Now, does that make you happy? All your ramblings about hos this is 
>stupid, not needed, and your attempts at calculating this information 
>through EOF pointers, and all that are still nonsense, but had you just 
>from the start said "hey, what you suggest has actually already been 
>implemented, and this is the field name for it", then none of this long 
>and stupid discussion would have been needed.
>
>>> Which is what I've said all along, and which you have also agreed is the
>>> case.
>>
>> I hve NOT agreed.  Read the post to which you have just replied to and have
>> elided all the proof.
>
>You want me to quote your post where you agreed that looking at eof and 
>ffby will not actually tell you the size? The whole history of this 
>thread is still available for all to read.

Well, IT DOES tell you the file size.  IT DOES NOT TELL YOU THE RECORDED DATA
SIZE!



>The information you posted now was a completely new piece of information 
>that I did not know, and which you never mentioned before either.
>Instead you've been arguing against me all the way when I asked for 
>exactly what it turns out have already been implemented.

I knew the size was made available somewhere but I couldn't remember the XAB
item.  I know I'd come across its internal implementation when I was working
on CDC but I never had any use for it in what I was doing/programming, so I
forgot about it until now.  It also has some limitations that I hope they'll
NOT bother to address.  IMHO, RMS doesn't need yet another lock to maintain
coherence for such information.

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

I speak to machines with the voice of humanity.