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

[Johnny Billquist]

On 2016-06-28 15:02, Bob Koehler wrote:
> In article <nks2in$3gn$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>
>> No it is not the number of bytes written in the file. As noted before,
>> the number of bytes written in the file can either be 1) The actual
>> number of bytes written in the file, which should then exclude padding
>> bytes at record ends, and padding bytes at block ends, or 2) the number
>> of bytes constituting the blocks written, since in the end, all writes
>> are in blocks.
>
>    If I write "hellow world\n" on UNIX, I get a different number of
>    bytes in the file than if I write it on Windows, even though my
>    application wrote the same thing.
>
>    So which one is the "number of bytes" _written_ "to the file"?

Since the OSes are different, the number of bytes written are different. 
Why do you expect that you will get the same number of bytes written in 
both cases?
However, reading the file with the proper low level functions (ie not 
the C stdio format library functions fgets(), which do some even funkier 
stuff when reading), you would get the same number of bytes read back as 
was original written to the file, and that would be the same number of 
bytes as reported by the stat() call. I would suggest reading with 
something like fgetc() or fread() if you are more impatient.

Very consistent, and very correct. In VMS it's neither. (Well, it is 
consistently wrong, which I guess is consistent... :-) )

Put it in very simple terms. If I have a file, and I do a stat() call, 
to find out how many bytes there are in the file, I should be able to 
call fgetc() that many times to get all the bytes in the file. Anything 
breaking this assumption means the reported size is wrong.

	Johnny