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

[Johnny Billquist]

On 2016-06-28 00:39, VAXman- at SendSpamHere.ORG wrote:
> In article <nks6g5$dk1$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>> 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:
>>>> 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.
>
> It *IS* the number of bytes used on the disk.  Explain how it is not.

The number of bytes used on the disk wold be a number evenly divisible 
by 512, and furthermore, it should be based on the number of blocks 
allocated, not whatever block is marked as the end block.

*That is the number of bytes used on the disk*

Anything else is not. If you disagree with me, be prepared for another 
fight. :-)

>> The number is in fact just an approximation of the number of bytes I
>> would get if I read the file.
>
> That can be true but it *IS* the number of bytes consumed by the file.

No it is not. See above.

The number is an approximation of the number of bytes I would get if I 
read the file, except under some special circumstances, when it would be 
exact. But since I can never know if those circumstances are met, I can 
only treat it as an approximation.

So: If I want to find out exactly how many bytes I would get if I read 
the file, there is no way of doing that, short of reading the file.
If I want to find out how much disk is used by the file, that number can 
be computed from file metadata, but your suggestion, as well as the C 
library stat() function under VMS, will not give me that.

>>> 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?
>
> Performance metrics are useful.  The may not make a file work better but they
> can be very useful to make use of the file better.  One of the things seen by
> RMS CDC was programs doing $OPEN/$UPDATE/$CLOSE for every file operation.  If
> knowledge can be derived from observation, things can be done to correct and
> or streamline operations.

So, we agree that it can be useful to keep and update more information 
than just the absolute minimum required by VMS or RMS itself. Good.

	Johnny