Extending file size using OSGBPB 1/3

[SteveF]

BeebWiki says (http://beebwiki.mdfs.net/OSGBPB):

If a write extends past EOF the file is extended, however the contents of the new part of the file are undefined unless overwritten.

Is there any way for an application to query the filing system to see if it guarantees to write zeros to the new part of the file without the new part needing to be overwritten, or does it have to assume the worst in order to be compatible with all filing systems?

DFS on the Master, at least, seems to write zeros anyway. although I must admit I'm a little bit confused here. The attached screenshot shows my test.

If I subsequently *DUMP the file, I can see everything from &100 on is zero. But I don't understand why the BGET# doesn't return an EOF error. I appreciate this is an odd sequence of operations to do in the first place, but I'd still like to understand it.

Edited to add: Actually I guess I've mixed things up slightly here with my test - I suspect BASIC's BGET# is not using OSGBPB. But I guess the same principle applies; I have some code which I can't conveniently post here which does actually use OSGBPB to extend a file and which shows the file being zero-extended on the Master DFS.

[lurkio]

I'm afraid I don't know the answer to your question, so, instead, here are some additional curious screenshots:

[jgharston]

BeebWiki says (http://beebwiki.mdfs.net/OSGBPB):

If a write extends past EOF the file is extended, however the contents of the new part of the file are undefined unless overwritten.

Is there any way for an application to query the filing system to see if it guarantees to write zeros to the new part of the file without the new part needing to be overwritten

Only by reading it back to see if it has been zeroed, or - more efficiently - explicitly zeroing it by writing zeros.

DFS on the Master, at least, seems to write zeros anyway. although I must admit I'm a little bit confused here. The attached screenshot shows my test.beebem.png If I subsequently *DUMP the file, I can see everything from &100 on is zero.

Being set to zero matches "undefined". Undefined means the implementation is completely free to do whatever the hell it wants to, including but not limited to zeroing the sectors, not zeroing the sectors, not allocating any sectors at all until they are actually written to, putting the cat in the microwave, emptying the washing machine.

But I don't understand why the BGET# doesn't return an EOF error.

Because you're not beyond the end of the file, you are at the end of the file so BGET correctly returns the carry flag set.

Edited to add: Actually I guess I've mixed things up slightly here with my test - I suspect BASIC's BGET# is not using OSGBPB.

Correct, BGET uses - as it's name explies, OSBGET.

[jgharston]

PS: typo alert if other readers get confused, you can't extend a file with OSGBPB 3 as that's read from open file. OSGBPB 1 and 2 are write to open file. Useful rule of thumb, 1,2 write, everything else reads, from file, disk title, directory name, directory contents, etc.

[SteveF]

Thanks Jonathan, that's helpful.

OSGBPB 3 wasn't a typo though - I observed that this does in fact extend (zero-extend, even) the file, on OS 3.20 with DFS 2.24 anyway. I didn't want it to do that, and I've now written my code to avoid triggering this behaviour, but here's a test program which shows it happening (also attached as a zipped SSD):

Code: Select all

ON ERROR CLOSE #0:REPORT:PRINT " at line ";ERL:END
DIM block% 256, data% 256
PRINT "*SAVE T.DATA 8000 C000"
*SAVE T.DATA 8000 C000
*INFO T.DATA
PRINT "*SAVE T.DATA 8000 8100"
*SAVE T.DATA 8000 8100
*INFO T.DATA
file%=OPENUP("T.DATA")
block%?0=file%
block%!1=data%:REM pointer for data read
block%!5=1:REM bytes to read
block%!9=&400:REM sequential pointer - past current file end
A%=3:REM get bytes using new sequential pointer
X%=block% MOD 256
Y%=block% DIV 256
osgbpb%=&FFD1:block%!200=USR(osgbpb%)
carry%=block%?203 AND 1
PRINT "carry ";carry%:REM not reliable?
PRINT "bytes left to transfer ";block%!5
IF block%!5=0 PRINT "byte read ";?data%
CLOSE #file%
*INFO T.DATA

I guess that either this program invokes undefined behaviour, or there's a bug in this version of the DFS. As I say, my program doesn't rely on this behaviour happening any more, it's just something I triggered during development.

[jgharston]

That's well wierd and functionally incorrect. What happens if the file is blocked from extending by another file? It would be particularly weird to get a 'Can't extend' error from a read operation.

After:
*SAVE T.DATA 8000 8100
add:
*SAVE T.BLOCK 8000 8100

so T.DATA can't be extended as it's blocked in by T.BLOCK

[SteveF]

It looks like it does give a "Can't extend" - here's an updated SSD with a TEST2 version of the program, and a screenshot.

I haven't experimented a great deal yet, but an (emulated) BBC B+ with DFS 2.26 behaves exactly the same, for what it's worth.

[sweh]

Hmm, I'm a little confused.

The first set of tests extended the file by setting PTR#, which uses OSARGS and not OSGBPB. BeebWiki says that extending a file in this way should write zeros ( http://beebwiki.mdfs.net/OSARGS#Functio ... dle.3C.3E0 ) but some filesystems have been observed not to.

The second set of tests _do_ use OSGBPB. However the Master Reference Manual (pt 1, section J.11) does not specify what should happen on reads when the PTR value exceeds EXT. The advanced user guide implies this should be an error for reads...

Definitely the actions are file system specific and shouldn't be relied on! But there's no way of knowing, in advance, how each filesystem will work.

(FWIW, the perl "TubeHost" program I wrote for HostFS:UPURS will extend with zeros on writes, and return an error condition - carry set - for reads)

[SteveF]

Hmm, I'm a little confused.

Sorry, I did get things a bit mixed up to start with - I had always been using OSGBPB 1/3 in the code I was working on which prompted this post, but when I came to write the first post I decided to illustrate the issue with PTR# as it was easier and I hoped/assumed it would be consistent.