Refuse a streamed file that commits more than it reserved

osFileStart sets an extent aside and osFileWrite refuses a block index outside
it, so writing off the end was already barred. Committing a larger size was
not, and reaches the same neighbour by simply claiming it: a directory entry is
the only record of what a file owns, so an entry claiming a block it was never
given owns it, and so does whatever owned it before. Both files then look
perfectly well formed. The free count went backwards past zero on the same
path.

Found by ChatGPT's review of the streaming work, in NOTES.md. I had bounded the
index because writing off the end was the obvious way to reach a neighbour, and
had not noticed that the other end of the same reservation was open.

THE SIZE IS COMPARED, NOT THE ROOM IT TAKES UP. One block and a tail occupies
exactly what two whole blocks occupy, so bounding the blocks alone would let a
file reserve the first, commit the second, claim no block it was not given, and
still report two hundred and forty six bytes that were never written to it -
whatever the disk had there before.

Checked before anything is touched, which is why the temporary is found twice.
The old file is deleted a few lines down and a refusal after that point would
have destroyed the thing it was protecting.

AND IT CAUGHT A REAL ONE IMMEDIATELY. The assembler reserves the file plus room
for its vectors, and asked for four bytes per vector DECLARED - which looks like
a safe bound and is not, because a device is declared during the SECOND pass, in
the line that implements it. A program with a device installs a vector that was
not counted when the room was measured. CosmOS reserved 14,163 bytes and
committed 14,167, writing four bytes past what it had been given on every build
since S2. It landed inside the last block it owned, and would not have if the
boundary had fallen four bytes earlier.

It reserves against the vector table's LIMIT now, which cannot go stale whenever
things are counted.

Claim.asm is the program that tries it: reserve one block and a tail of ten,
write them, then tell osFileDone the file came to two whole blocks. The refusal
and the honest commit that follows are both recorded.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
This commit is contained in:
Anachronaut
2026-08-25 20:20:39 -04:00
co-authored by Claude Opus 5
parent 19ab36a201
commit a7d3e09d94
7 changed files with 264 additions and 19 deletions
+77 -15
View File
@@ -2474,6 +2474,61 @@ sbfsStreamDone:
SETD.1 SbfsStreamNewTail
STA.1
; ---- MORE THAN WAS RESERVED IS REFUSED ----
;
; A writer may finish smaller than it asked for, which is the whole point of being told
; the size here. It may not finish BIGGER. The blocks after a file belong to whatever
; comes next, so an entry claiming more than was set aside for it claims somebody else's
; - and nothing anywhere would say so, because a directory entry is the only record of
; what a file owns. The count of free blocks would go wrong in the same breath, the
; subtraction below running backwards past zero.
;
; osFileWrite already refuses a block index past the end. This is the same bound from the
; other side, and it was missing: the index was checked because writing off the end was
; the obvious way to reach a neighbour, and committing a larger size reaches the same
; neighbour by simply claiming it.
;
; CHECKED BEFORE ANYTHING IS TOUCHED, which is why the temporary is found twice. The old
; file is deleted a few lines down, and a refusal after that point would have destroyed
; the thing it was protecting.
CALL sbfsStreamTemp
CALL sbfsScanFor
BNQ sbfsStreamNo
; What it was given, both halves of it.
SETD.0 SbfsStreamResBlocks
SETD.2 SbfsFileBlocks
CALL sbfsSetWord
SETD.0 SbfsFileTail
LDA.0
SETD.1 SbfsStreamResTail
STA.1
; And the room that came to, kept for the free count at the end.
CALL sbfsFileExtent
SETD.0 SbfsStreamSpare
SETD.2 SbfsWantBlocks
CALL sbfsSetWord
; THE SIZE IS COMPARED, NOT THE ROOM IT TAKES UP. Those are not the same question: one
; block and a tail occupies exactly what two whole blocks occupy, so a file reserving the
; first and committing the second claims no block it was not given - and still reports
; two hundred and forty six bytes more than were ever written to it, which are whatever
; the disk had there before. Bounding the blocks alone would have called that fine.
SETD.0 SbfsStreamResBlocks
SETD.2 SbfsStreamNewBlocks
CALL sbfsCompareWord
BRC sbfsStreamNo ; More whole blocks than it was given.
BNQ sbfsStreamFits ; Fewer, so the tail cannot matter.
SETD.0 SbfsStreamResTail
LDA.0
SETD.2 SbfsStreamNewTail
LDB.2
CCF
SUB
BRC sbfsStreamNo ; The same blocks, and a longer tail.
sbfsStreamFits:
; Now, and not before, the old one goes. It may not be there at all, which is what
; writing something for the first time looks like from here.
CALL sbfsStreamWhere
@@ -2483,17 +2538,12 @@ sbfsStreamDone:
sbfsStreamNoOld:
; And the temporary takes its name and its true size, which together are the whole of
; what committing is.
; what committing is. Found again, because deleting the old one read over the block it
; lives in.
CALL sbfsStreamTemp
CALL sbfsScanFor
BNQ sbfsStreamNo
; How much room it was given, before the entry that says so is changed.
CALL sbfsFileExtent
SETD.0 SbfsStreamSpare
SETD.2 SbfsWantBlocks
CALL sbfsSetWord
PSHD.3
POPD.1
DPUP.1 0d06
@@ -2517,14 +2567,9 @@ sbfsStreamNoOld:
CALL sbfsWriteBlock
BNQ sbfsStreamNo
; And the difference goes back, which is what it was given less what it kept.
SETD.0 SbfsFileBlocks
SETD.2 SbfsStreamNewBlocks
CALL sbfsSetWord
SETD.0 SbfsStreamNewTail
LDA.0
SETD.1 SbfsFileTail
STA.1
; And the difference goes back, which is what it was given less what it kept. That can
; no longer be negative: the check at the top refused the only case where it could.
CALL sbfsStreamSize
CALL sbfsFileExtent
SETD.0 SbfsStreamSpare
SETD.2 SbfsWantBlocks
@@ -2557,6 +2602,19 @@ sbfsStreamNoOld:
ADD
RET
; The size the writer says it came to, put back where the extent arithmetic reads it from.
; Said again rather than kept, because finding anything overwrites those two: they are where
; a find describes whatever it last looked at.
sbfsStreamSize:
SETD.0 SbfsFileBlocks
SETD.2 SbfsStreamNewBlocks
CALL sbfsSetWord
SETD.0 SbfsStreamNewTail
LDA.0
SETD.1 SbfsFileTail
STA.1
RET
; The directory the file is going in, and the name it will end up under. Said again before
; each step, because every step goes to the disk and leaves the walk somewhere else.
sbfsStreamWhere:
@@ -2880,6 +2938,10 @@ SbfsStreamNewTail:
0x00
SbfsStreamSpare:
0x00 0x00
SbfsStreamResBlocks:
0x00 0x00
SbfsStreamResTail:
0x00
SbfsStreamAt:
0x00 0x00
SbfsStreamParent: