smbfs 1.103 (14.4.2016)
- Added DUMPSMBLEVEL option which controls how much raw
data output is produced. By default (level 0) no raw
data output is produced at all. Level 1 will print the
contents of the command data area. Level 2 will print
the raw data used by the respective commands, with any
management/control information stripped off.
smbfs 1.104 (16.4.2016)
- For smb_request_write_raw() return values of 0 now indicate success.
- Simplified the raw read portion of smba_read() by removing the test
that avoids dropping into a read loop below. The loop handles the
special case well.
- Recalculated the overhead for SMB_COM_READ. It's still 52 bytes,
but now the documentation states how this number comes about.
- Recalculated the overhead for SMB_COM_WRITE. It's 52 bytes and
not 56 bytes.
- Recalculated the overhead for the SMB_COM_WRITE_RAW command, and
it's 63 bytes, not 4.
- Unless smb_proc_write_raw() finds that sending the packet results
in a transmission error, it will try to pick up the server responses.
Previously, it would not even try that, which could deadlock the
client<->server message exchange.
smbfs 1.105 (16.4.2016)
- Fixed decoding of maximum buffer size; this used to come out
as 0, which made smbfs switch back to the default minimum
supported (1024 bytes).
- Corrected use of the maximum raw write size as the size used
by the client to perform raw reads with. The maximum allowed
are 65535 bytes for a raw read request. Likewise, the
maximum raw write size is 65535 bytes, too.
smbfs 1.106 (17.4.2016)
- More detailed error class/code translation information now
shows up in the debug log.
- The SMB dump output can now be stored in a file, rather than
having to be redirected to one. When storing it in a file,
the output will be appended to an existing file, otherwise
a new file will be created.
- The raw read/write functions now respect the upper limit
for the amount of data to be written, as given by the server.
smbfs 1.107 (20.4.2016)
- Added WRITEBEHIND and PREFERWRITERAW options. WRITEBEHIND will
allow SMB_COM_WRITE_RAW commands to complete asynchronously.
PREFERWRITERAW will make the file system use SMB_COM_WRITE_RAW
over SMB_COM_WRITE when it has a choice.
smbfs 1.108 (23.4.2016)
- Now properly handles the error code returned when Samba
is asked to remove a non-empty directory. The error is
translated to ENOTEMPTY.
smbfs 1.109 (23.4.2016)
- Activated the PREFERWRITERAW option which had not been wired
up yet. Oops :-( Turns out that with this option enabled
write operations are indeed slower than the with the
adaptive SMB_COM_WRITE/SMB_COM_WRITE_RAW code, on account that
that SMB_COM_WRITE_RAW transmits the data in two packets, plus
overhead for the server response.
- Recalculated the threshold below which a write operation will
be performed using SMB_COM_WRITE instead of SMB_COM_WRITE_RAW.
- Fixed how the WRITEBEHIND option for the SMB_COM_WRITE_RAW
command is implemented: the client must not wait for the
server to acknowledge the command.
- Investigated the performance difference between SMB_COM_WRITE_RAW
using the "write behind" and "write through" modes. In my tests
the difference came down to about 10% performance gain for
the "write behind" mode.
- Compared the performance of plain SMB_COM_WRITE (Windows 7) and
the adaptive SMB_COM_WRITE/SMB_COM_WRITE_RAW (Samba 3.0.25).
The adaptive SMB_COM_WRITE/SMB_COM_WRITE_RAW is about as fast
as the plain SMB_COM_WRITE, with "Windows 7" running on the
same machine as WinUAE (with AmigaOS 3.9) and Samba running
on a local server connected via GBit Ethernet. This means that
SMB_COM_WRITE is significantly slower with Windows 7.
smbfs 1.110 (1.5.2016)
- Added the DEBUGFILE/K option. Not everybody has Sashimi or
a tool like it running in the background, which makes sharing
file system level debug information difficult.
smbfs 1.111 (11.5.2016)
- You can now identify smbfs by checking the DosList->dol_misc.dol_volume.dol_DiskType
field. It will read back as 0x534D4200, which is equivalent to the signature
"SMB\0". This change was suggested by Chris Handley and Chris Young.
Thank you very much!
smbfs 1.112 (26.9.2016)
- The negotiation in smb_proc_reconnect() picked up the server's
maximum buffer size and then always added 4 bytes on top of it.
From the looks of it, this was intended to account for the
4 byte NetBIOS session header to be prepended to each SMB
command block. In practice it could push the size of a
write operation beyond what the server would accept.
smbfs 1.113 (29.9.2016)
- Removed the SMB_HEADER_LEN constant, since it wasn't actually referring to the
length of the SMB header, but the NetBIOS session header plus the SMB header.
This led to some confusion as to what exactly the packet byte offsets used by
"proc.c" would reference.
- "proc.c" now lists the byte offset values into the packet buffer, so as
to make it clearer what exactly is being referenced.
- smb_valid_packet() now correctly displays the expected and actual
- smb_setup_header() no longer includes the NetBIOS session header
in the total message length calculation. Which means that smbfs
no longer sends packets with a NetBIOS header which claims that
the messages should be longer than they actually are.
- smb_proc_write_raw() no longer cares about the number of
command words, but only about the number of data bytes and
the command, when waiting for a raw write operation to
smbfs 1.114 (1.10.2016)
- The packet buffer size is now increased during the protocol
negotiation, if the default buffer size proves to be too
small. This avoids trouble with the MAXTRANSMIT option,
which used to leave the original packet buffer size
unchanged, and too short.
- The raw write operation no longer stumbles into a 0 length
write, which the server would not expect and not respond to.
- Moved the test for the "write behind" option in the
raw write operation so that it is handled before the
server response (which hasn't arrived yet) is checked.
- Verified that the raw write operation can deal properly
with the server response (interim update and write
smbfs 1.115 (2.10.2016)
- The MAXTRANSMIT option controls how much data smbfs is
prepared to receive. That value cannot be smaller than
8000 bytes, and it cannot be larger than 65535. The
code which sets up this parameter and verifies that it
is in range is now implemented only once, and not
twice in different places.
- The MAXTRANSMIT option also controls how much data
smbfs may send to the server. This limit is no longer
capped at 65535 bytes.
- The size of the message reception/transmission buffer
can no longer be smaller than 8000 bytes and it cannot
be smaller than the number of bytes which may be sent
to the server.
smbfs 1.116 (3.10.2016)
- smb_receive_trans2() now verifies that the amount of
data received is not larger than the maximum acceptable
by the client. Previously, it compared the amount of
data received against the server's upper limit. Ouch :-(
- smba_readdir() now stops immediately if no directory
entries are supplied. Previously, it could deliver
a bogus directory entry to the scanning function.
- The number of directory entries accepted by smb_proc_readdir_short()
is now calculated according to how much data the client will
accept, and not according to the server's limit.
- smb_proc_readdir_long() now reports how much data the
client will accept, rather than how much the server will
accept. This was problematic because that number is a
16 bit value, and the server's maximum transmission
value could be larger than 65535 bytes, causing directory
scanning to fail because the truncated 16 bit value
could be too tiny to report even a single result.