If the Examine/ExNext/ExAll functions need to restart directory scanning, the cache maintained by the smbfs directory reader is now always cleared.
Removed the directory cache expiration time feature, along with the just-introduced CACHEEXPIRES option. The context in which the expiration time was used did not justify it as a feature. It looked more like a bug...
Rewrote the smba_readdir() function to perform its only task in a much simpler manner. It now either fills the directory cache or retrieves the cache entries to be delivered to the caller, resuming the retrieval at a predefined position if required.
smb_proc_readdir_short() now updates the scan resume information for every directory entry it can process and actually uses the scan resume information when asked to resume scanning.
If the directory cache becomes stale before the contents have been processed, scanning will have to be restarted. smbfs now tells the server that the scan operation has been aborted before it is started again.
Directory scanning in combination with deletion operations can collapse if the directory cache becomes stale before all the relevant entries have been processed. You can now tune how long the cache will remain active, which previously was a period of 5 seconds. The current default is 10 seconds, which definitely helps. Use the new CACHEEXPIRES option to change how long the cache is considered good enough.
Documented the directory cache a bit better, including the reason why the cache may have been invalidated while the directory contents were being read.
The directory read operation now verifies that it does not run out of cache entries while it is processing new directory records it received from the server.
The directory read operation now both detects whether or not the last entry has been read, this information is now also provided to the function which retrieved the directory entries. This change is in support of improved directory entry caching.
The directory cache now keeps better track of what's actually in it. If a directory entry could not be extracted and decoded, the number of directory entries read would not match the number of entries available from the cache, for example.
A flag now tracks if the directory cache is valid or not. Previously, checking for a valid cache involved looking at a NULL pointer.
If allocating memory for the directory cache failed partly, then there may have been invalid string pointers in the cache table, leading to a crash when trying to release the cache. Fixed.
Adding another entry to the cache, invalidating the cache or resetting the cache now all use dedicated functions instead of directly manipulating the assorted data structures.
Found a couple more cases in which debug output did not use the correct parameter information. This happened, for example, in the SMB write operation (which did not correctly report the 64 bit seek offset) and the ACTION_SET_COMMENT implementation which did not print the comment string correctly.
Added a proper string length limit check for the text buffers used by the DateToStr() function.
Enabled profiling support for SAS/C to learn more about the most frequently-used functions and their respective running times. Added inline qualifiers to these functions, or copied the respective function to where it was called, allowing it to be inlined.
The main file system processing loop no longer calls WaitSelect() every time it needs to wait for a new packet to arrive, or for a NetBIOS "keep alive" message to come along. It now defaults to calling Wait(), which has a much lower overhead than WaitSelect(). However, periodic calls to WaitSelect() and the associated NetBIOS "keep alive" handling are scheduled regularly every 10 seconds. That way the "keep alive" messages are dealt with without spending too much time with WaitSelect().
The ACTION_SETDATE operation again changes both the file/directory creation date/time and the last modification date/time. Because some SMB servers will not return a valid modification date/time, the creation date/time will be substituted when directory entry information is converted into the appropriate AmigaDOS data structures. This is problematic if only the modification time/dated is updated by the ACTION_SETDATE operation because the change may appear not to "stick".
The SMB function which would be used to update both the modification and the creation time stamps did not take care to preserve the creation time stamp. This might have contributed to the ACTION_SETDATE operation not having a noticeable effect.
The debug code no longer uses FORMAT_DEF for converting AmigaDOS time stamp information into readable text, but uses FORMAT_DOS instead. This is an attempt to track down a hard to detect bug in the debug code which might be related to locale.library date conversion. Because the buffer size for the date and time information is limited, the locale settings might just produce too much text to fit into the buffers. But that's only a theory so far...
The functions which the debug code uses to prepare 64 bit integers and strings for display are now a bit more paranoid in watching the lengths of the resulting strings, reporting possible buffer overflows.
Went over all the debug output text format strings with a fine-toothed comb and actually found a few instances of the formatting parameters not being entirely correct.
The assert.c code makes a bit more of an effort to handle NULL strings for display.
The non-debug builds of smbfs now complain again if any of the debug parameters are being used.
The smb_receive_raw() function in "sock.c" again copies the NetBIOS header into the receive buffer separately, rolling back an earlier change which did not seem to be sound, and also served to make complicated code even more complicated :-/
Added the SCATTERGATHER tuning option which defaults to "no". Instead of breaking down write operations into two separate send() calls (one short, one very large), setting SCATTERGATHER=yes can call sendmsg() instead which allows the entire operation to be completed in one single step. This approach was suggested by Patrik Axelsson. Currently, I am uncertain if all AmiTCP V3/V4 TCP/IP stacks implement sendmsg() for TCP sockets in the same consistent manner, which is why this feature is not enabled by default.
Added the WRITETHRESHOLD parameter which can be used to disable the separate transmission of the SMB message header and its payload if the combined sizes of both are smaller than or equal to the threshold value. This is intended to improve write performance for small amounts of data which would otherwise linger in the transmission queue.
Added the READTHRESHOLD counterpart to WRITETHRESHOLD which affects the read operations.
The smb_receive_raw() function in "sock.c" no longer copies the NetBIOS header into the receive buffer separately, but makes sure that the initial receive operation takes care of it.
The allocate_path_name() function in "smb_abstraction.c" failed to put the path separator character where it should be, resulting in the path name and the file/directory name to get lumped together. This affected creation of files and directories both.
The default values for READTHRESHOLD and WRITETHRESHOLD now have the effect of transmitting the SMB header and the payload separately, just like it was introduces in version 2.1.
Use something like READTHRESHOLD=1500 and WRITETHRESHOLD=1500 to send packets smaller than or equal to 1500 bytes as a combined lump of data, and data larger than 1500 bytes as separate SMB header and payload.
When processing the share name the limitations on the individual components (server name, share, port number/IP service name) are no longer verified using hard-coded lengths, but use the respective buffer limits instead. The port number/IP service name length check is new.
Added more debug log output to the code which now performs the file and lock name/address lookups instead of walking throug the entire file/lock lists.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
Please keep in mind that this is still a development version and might surprise you (not necessarily in a good way).
Do not let me discourage you to build and test this version, although there will be some risks involved such as data corruption or loss of data.
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.
Decoding is performed before the session header type is checked and, if necessary, rejected.
smb_receive_raw() now only accepts a single session header type (message) and rejects all others. At this stage "positive session response" should no longer appear.
Made a note of the fact that the SMB_COM_READ_RAW may be followed by more than one response by the server. The current implementation only catches one response.
The data transmitted by the SMB_COM_WRITE_RAW command is no longer decoded as if it were an SMB message.
Major rework of the code which decodes individual commands, their parameters and the responses. This is still incomplete, but it's a lot more useful now than before.
The word/dword conversion code should be more robust now, using type casts where needed.
Cleaned up numeric comparisons, so that the types of the quantities compared match.
The SMB packet dump code now prints the current transmit buffer size along with the other packet information.
All commands which the smbfs program receives or send through the network can now be decoded, printing header information and (eventually) more detailed information about the specific server command. This option is enabled at compile time.
- In proc.c, smb_setup_header() initialized the SMB header length
field with a number which was too large by four bytes. Consequently,
what was later committed to the wire would have four trailing data
bytes which could contain random values. This often didn't do much
harm, but it seems that Samba 3.2.4 and Windows Vista don't like the
looks of the trailing junk bytes.
git-svn-id: file:///Users/olsen/Code/migration-svn-zu-git/logical-line-staging/amiga-smbfs/trunk@20 26594b9e-b914-4e86-b7a1-9402bd427170
Olaf Barthel
obarthel