The SMB2 1.x client stack in sigilOS is now fully round-trippable. smb2_close and smb2_seteof land today, completing the handle lifecycle from negotiation to release. A sigilOS process with Cap<Network> can now open a file on a Windows share, write to it, set its size, and close it — all through the VFS dispatch layer, all cap-gated.
smb2_close: releasing a file handle
smb2_close_call(buf, mid, fh_id) builds the SMB2 CLOSE request (command 6). The request body carries the compound persistent and volatile file handle IDs from the 16-slot fhandle table. On success, smb2_close_parse verifies the response StructureSize is 60 — the fixed size for a CLOSE response — and marks the fhandle slot free for reuse.
This is the cleanup gate. Every CREATE acquires a slot; every CLOSE releases it. Without CLOSE, the server holds the handle open and the slot table fills. With CLOSE wired, sigilOS can open and release files in a loop without leaking server state.
smb2_seteof: server-side truncation and extension
smb2_seteof_call(buf, mid, fh_id, new_size) builds an SMB2 SET_INFO request (command 17) with InfoType=SMB2_0_INFO_FILE(1) and FileInfoClass=20 (FileEndOfFileInfo). The 8-byte EndOfFile value is written at body offset 32, making it absolute offset 96 from the message start.
SET_INFO/FileEndOfFileInfo is the standard SMB2 mechanism for truncating or extending a file without sending data — the server adjusts the file size directly. This is what a file manager uses when creating a pre-sized file, or what a database uses when extending a log.
SMB2 SET_INFO request layout:
offset 0: SMB2 header (64B)
offset 64: StructureSize=33, InfoType=1, FileInfoClass=20
offset 72: BufferLength=8, BufferOffset=96, Reserved, AdditionalInfo=0
offset 88: FileHandle (persistent + volatile, 8B each)
offset 96: EndOfFile (8B, little-endian)smb2_seteof_parse delegates to smb2_hdr_check, which validates the response Status (must be STATUS_SUCCESS) and command echo (must be 17). A non-zero Status — file not found, access denied, out of disk — surfaces as a negative return from the VFS layer.
What's next for the SMB2 stack
The 1.x lifecycle is complete. The remaining work is TCP transport binding — currently the SMB2 codec layer returns -2 (kernel TCP pending) for operations that require a live connection, because the kernel TCP stack integration is a 0.6.0 item. Once tcp_connect and tcp_send/tcp_recv are wired, the SMB2 codec layer has everything it needs to talk to a real Windows or Samba server. The codec itself is done.
QUERY_DIRECTORY (remote directory listing) is also implemented — sigilOS can list the contents of a mounted Windows share directory through the same VFS dispatch layer. The full read path (NEGOTIATE → mount → QUERY_DIRECTORY → READ) and the full write path (CREATE → WRITE → SET_INFO → CLOSE) are both codec-complete and waiting on TCP.