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

[Johnny Billquist]

On 2016-06-27 17:08, VAXman- at SendSpamHere.ORG wrote:
> In article <nkr95m$vvh$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>> On 2016-06-23 23:17, VAXman- at SendSpamHere.ORG wrote:
>>> In article <nkherb$71o$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>> You only even get a potential gain from this, if you then cache either
>>>> the converted file, or the figured out size (I would actually just cache
>>>> the figured out size, since that takes way less memory.)
>>>
>>> How do you get the size on unix?  stat()?  Why can't you or won't you do the
>>> equivalent on VMS?
>>
>> Because VMS do not have the information required? The whole reason that
>> this thread exist...
>
> https://www.youtube.com/watch?v=2LScoi7pK68
>
> It does!  It may not be there jumping up and down waiving a flag and screaming
> "here's the byte count" but it's readily and easily obtained; however, as I've
> stated time and time again, it may not mean what you want it to be.

Sigh. So what this argument now boils down to is that you have decided 
to have a different definition to what the byte count would be, and thus 
it is available by your definition, it is not usable for my needs, so 
its my problem.

Sure. Have your definition. See how nobody cares about a meaningless 
number and be happy.

>>>> Not to mention that converting everything to stream files is not always
>>>> what I want. Not to mention the issues with keeping track of, and
>>>> maintaining duplicates of files, and the amount of extra disk space this
>>>> might take. As mentioned in another response...
>>>
>>> If you want to serve a VMS file as a stream file, then why not maintain it
>>> as a stream file.  You've being argumentative for argument sake.  There's
>>> a way to get the file size in bytes but it'll be the real file's size and
>>> that'll depend on the file format(s).  A RFM=VAR, RFM=VFC, and RFM=STM can
>>> maintain all of the same *record* data but they will not necessarily have
>>> the same number of bytes in their files.  But, hey, I gave you the answer,
>>> but you don't or refuse to hear it.  Take a little time to learn about RMS
>>> file and record formats.  If that's too much, put your HTTP server over on
>>> *ix where you'll be happy.
>>
>> Because the file is not a stream file to start with. The file already
>> exists, and I want to serve it.
>
> Then, serve it.  It's the fault of the recipient that it can't understand it.

Uh, the receiver understands it just fine. It's just that I need to find 
the size of the file before I serve it.

I mean, how hard can it be to understand what I am saying? This is not 
about the file content, but just about the size of it.

> If it can't, then you need to convert it (as you've said, you synthesize the
> necessaries) and thus, you need to synthesize an appropriate byte count.

Cheesus. It feels like I'm explaining the same thing over and over 
again, and you just refuse to understand.
I guess I should force you to write the code instead. I suspect that 
would make you understand...

>> You are the one being argumentative for arguments sake.
>> If I have a file, I already have a file. Starting to argue about that
>> you could have some other file, and then you could easily calculate the
>> size of *that* file is a meaningless argument. I have the file I have.
>> That is where this starts.
>
> It's hopeless...

I think I agree.

> I suppose that the only thing that would satisfy you would be to maintain a
> byte count of every possible record format when the file's records are added
> or updated.  I've spent at least 5 years with my head in the bowels of RMS on
> VMS and I could probably wedge that in there for you but why?  I know why you
> say why but it serves no VMS, file system or RMS purpose.

No. I'm merely suggesting have one byte count on the file, and that's 
it. There is no point, or need, to keep track of different record 
formats. You call $PUT in RMS, the record gets written. RMS will check 
and update the end of file information, as well as the first free byte. 
It also keeps track of the longest record.
(This is all done today.)
In addition I suggest adding a byte count value that is updated at each 
$PUT. You just add the length of the record put to that byte counter. 
And also you increment a record counter. And that's it.
Nothing more needed. Not much overhead, and not much storage. 64 bits 
for both fields would be fine.

And no, VMS, nor RMS itself, really needs or would use this information. 
But some applications will. There are other stuff RMS does which serves 
no purpose for RMS itself as well. (What part of RMS or VMS cares about 
the revision count for example?)

	Johnny