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

[Johnny Billquist]

On 2016-06-27 19:36, Johnny Billquist wrote:
> On 2016-06-27 18:55, VAXman- at SendSpamHere.ORG wrote:
>> In article <nkrhao$lkq$1 at Iltempo.Update.UU.SE>, Johnny Billquist
>> <bqt at softjar.se> writes:
>>> On 2016-06-27 17:19, VAXman- at SendSpamHere.ORG wrote:
>>>> In article <nkrbmt$7k8$2 at Iltempo.Update.UU.SE>, Johnny Billquist
>>>> <bqt at softjar.se> writes:
>>>>> On 2016-06-23 23:40, VAXman- at SendSpamHere.ORG wrote:
>>>>>> In article <nkhf0u$71o$2 at Iltempo.Update.UU.SE>, Johnny Billquist
>>>>>> <bqt at softjar.se> writes:
>>>>>>> On 2016-06-23 21:42, VAXman- at SendSpamHere.ORG wrote:
>>>>>>>> In article <nkhdao$2us$3 at Iltempo.Update.UU.SE>, Johnny Billquist
>>>>>>>> <bqt at softjar.se> writes:
>>>>>>>>> And now you are creating alternative files for requested files,
>>>>>>>>> and need
>>>>>>>>> to keep track which ones you have created an alternative for, and
>>>>>>>>> substitute one for the other for those cases. I can see how
>>>>>>>>> this can
>>>>>>>>> become rather exciting over time...
>>>>>>>>
>>>>>>>> Overwrite the existing.  It's text and VMS can read it because
>>>>>>>> it'll see the
>>>>>>>> record format.
>>>>>>>
>>>>>>> Whoa! I don't know about you, but personally I would be extremely
>>>>>>> pissed
>>>>>>> if a tool that is supposed to only read my file were to modify
>>>>>>> it. Even
>>>>>>> if the contents supposedly should appear to look the same
>>>>>>> afterwards.
>>>>>>>
>>>>>>> But you're even making some pretty horrible assumptions here.
>>>>>>> Assuming
>>>>>>> that the file even is a text file to start with, for which
>>>>>>> conversion to
>>>>>>> a stream, might be assuming too much.
>>>>>>
>>>>>> If it's not text, then what does it matter?  Binary?
>>>>>
>>>>> So you have a sequential file with variable size records, and no file
>>>>> attributes. How do you find the size?
>>>>
>>>> Why would the file attributes matter?
>>>
>>> If you get a request for a file, it matters greatly if it has implied
>>> CRLF or not. If it does, you should add an explicit CR+LF at each record
>>> end, when sending the file. If it does not have this attribute, you
>>> should definitely not add a CR+LF at each record end.
>>
>> That'so not a file attribute.
>
> Ok. So I should have said record attribute. My mistake.

I bet you even knew this...

>>> I did not expect I should have to explain such basic things to you. Were
>>> you really serious with this question?
>>>
>>>> file_size_in_bytes = <end_of_file_block-1>*512 + <end of file byte>
>>>>
>>>> ... but it won't mean what you want it to mean.
>>>
>>> That number is certainly a number. It is not a number I ever expect
>>> anyone would find useful for anything, so why do you even bring it up?
>>
>> Because it's THE file size.
>
> No it is not. It's an arbitrary number you decided to calculate.
> Why would that be any more valid than just <end-of-file-block>*512. Why
> do you care about the first free byte information at the end if you
> don't care about the free bytes in other records?

Free bytes in other blocks, I should have said.

> And why just calculating based on the end-of-file-block and not
> allocated blocks?

I would argue that this would actually be more useful than your weird 
file "byte size".

	Johnny