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

[VAXman- at SendSpamHere.ORG]

In article <nl0gec$fke$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-29 14:15, VAXman- at SendSpamHere.ORG wrote:
>> In article <nl0125$ecv$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>> 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. :-)
>>
>> See how well that works for you when you need to append a chunk of data (ie. a
>> record) to your files.
>
>It's still the number of bytes used on the disk. Can't help if that is 
>not what you are actually looking for at some specific point in time.
>
>> Blocks are the container for the file, much like a bottle contains a fluid.  I
>> want the fluid the bottle contains, not the air space encapsulated with it.  In
>> that vein, the number of bytes in the file, as per my computation, is where my
>> bottle of fluid's meniscus exists.  If I add to the bottle's fluid (block), it
>> continues adding to the volume until I can add no more. At that point, I'd need
>> another bottle (block).  When I buy beer, for example, it is taxed per volume
>> (fluid oz. or millilitres) of the beer, not the bottle.  The bottle(s) and the
>> carrier are incidentals for management/storage/mobility.
>
>The bottle takes up the same about of volume in my room no matter if it 
>is empty or full. I just claimed that the actual space used by a file is 
>the number of blocks allocated, no matter what data I did, or did not 
>put in there. The same as my bottle taking the same volume in my room, 
>no matter if I put something into the bottle or not. I can only put n 
>bottles in my room, no matter how I use the space inside the bottle.
>
>> So, it IS the size of the file on disk.  If the file system allocates larger or
>> more bottles for the file, it doesn't make the fact that the file is 'n' bytes.
>
>It is not the size of the file on the disk. Simple as that.

You're too thick.

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

I speak to machines with the voice of humanity.