Extending file size using OSGBPB 1/3

Discuss all aspects of programming here. From 8-bit through to modern architectures.
SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Extending file size using OSGBPB 1/3

Postby SteveF » Thu Dec 29, 2016 5:28 pm

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.
beebem.png
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.
Last edited by SteveF on Thu Dec 29, 2016 8:32 pm, edited 1 time in total.

User avatar
lurkio
Posts: 1284
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Extending file size using OSGBPB 1/3

Postby lurkio » Thu Dec 29, 2016 6:15 pm

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

Untitled 4.png
Untitled.png

:-s

User avatar
jgharston
Posts: 2756
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Extending file size using OSGBPB 1/3

Postby jgharston » Thu Dec 29, 2016 9:05 pm

SteveF wrote: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.

SteveF wrote: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.

SteveF wrote: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.

SteveF wrote: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.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2756
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Extending file size using OSGBPB 1/3

Postby jgharston » Thu Dec 29, 2016 9:14 pm

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.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Extending file size using OSGBPB 1/3

Postby SteveF » Sat Dec 31, 2016 1:16 am

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

test.png

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.
Attachments
test.zip
(614 Bytes) Downloaded 10 times

User avatar
jgharston
Posts: 2756
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Extending file size using OSGBPB 1/3

Postby jgharston » Sat Dec 31, 2016 10:32 am

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

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Extending file size using OSGBPB 1/3

Postby SteveF » Sat Dec 31, 2016 11:50 am

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.
test2.png

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.
Attachments
test2.zip
(11.66 KiB) Downloaded 11 times

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Extending file size using OSGBPB 1/3

Postby sweh » Sat Dec 31, 2016 1:46 pm

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)
Rgds
Stephen

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Extending file size using OSGBPB 1/3

Postby SteveF » Sat Dec 31, 2016 8:11 pm

sweh wrote: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.


Return to “programming”

Who is online

Users browsing this forum: No registered users and 1 guest