[Info-vax] Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT)
Johnny Billquist
bqt at softjar.se
Tue Jun 21 12:34:55 EDT 2016
On 2016-06-21 18:18, VAXman- at SendSpamHere.ORG wrote:
> In article <nkbn1q$5cn$2 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>> On 2016-06-19 04:35, David Froble wrote:
>>> Jan-Erik Soderholm wrote:
>>
>>>> Yes, but that is a simple calculation with 1 block = 512 bytes.
>>>> It does not correctly display partially filled blocks. I guess
>>>> that what most here are talking about is the size up to the
>>>> marker. Convering the used/allocated number of blocks is simple.
>>>>
>>>> Jan-Erik.
>>>
>>> I would suggest "what does it matter?"
>>>
>>> It's not like some other file is going to use the unused portion of some
>>> disk block, or, as suggested, unused part of 4096 bytes ....
>>
>> No. But if you implement FTP, or a web server, or any number of other
>> tools/programs, they are expected to report file sizes in bytes, and the
>> byte count should be *accurate*. Even one byte off is not acceptable.
>
> Why?
Because the frickin' protocol specs say so? :-)
And because other software then assumes that if the spec says so, then
they can rely on it, and consequently will only read that many bytes
before considering the transfer to be complete. If you then send fewer
bytes than you claimed the size was, the other end will wait until the
end of time for those additional bytes to put into the receiving end.
And if you actually send more bytes, then the receiver will ignore them.
Either way, if it's actually a transfer of a file, the file on the other
end will end up not having the same content. I don't know about you, but
around here, that is considered to be a broken transfer...
>> And that becomes costly if your system do not keep that information, and
>> you have to calculate it yourself.
>
> $ SEARCH file.txt ""/NOOUTPUT/STATISTICS
>
> Files searched: 1 Buffered I/O count: 5
> Records searched: 255 Direct I/O count: 1
> Characters searched: 11333 --. Page faults: 20
> Records matched: 255 | Elapsed CPU time: 0 00:00:00.00
> Lines printed: 0 | Elapsed time: 0 00:00:00.00
> `---------------.
> $ DUMP/HEADER/BLOCKS=COUNT=0 file.txt |
> : |
> : |
> Highest block: 32 |
> End of file block: 24 |
> End of file byte: 220 |
> : |
> : |
> File length hints |
> Record count: 255 |
> Data byte count: 11333 <---'
> :
> :
>
> (24-1)+220 => 11996
>
> Which is right? 11333? 11996? Neither?
Are you asking me? :-)
It would, of course, depend on what you actually want to know...
Johnny
More information about the Info-vax
mailing list