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 packet size. - 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 conclude. 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 completion). 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. |