The proof of concept implementation of mapping the original UTF16LE-encoded path names to hashed versions in the ISO-Latin-1 encoded space did not scale well and would invariably leak memory because there is no safe way to determine whether such a mapping was no longer needed. There appears to be no way to make this work robustly.
So, sadly, I removed Tygre's implementation.
We are back to square one with mapping UTF16LE-encoded path names, and also with mapping file/directory names longer than 107 characters (Windows names can be up to 127 characters long).
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.
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 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.
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.
All functions now follow a consistent error reporting scheme. A negative return value always indicates an error condition. A return value of 0 always indicates success, except for the few functions which have to return a count of bytes or directory records upon success.
Previously, it was hard to tell what function returned what in case of error, which led the bugs in smba_write() and smba_read(), neither of which gracefully fell back on SMB_COM_WRITE/SMB_COM_READ, respectively if SMB_COM_WRITE_RAW/SMB_COM_READ_RAW failed.
State variables are now named according to their respective purpose where possible. Previously, it was "rval", "errnum", "result" which were used almost interchangeably regardless of purpose.
Because the field and variable name "max_xmit" was used in four different places, with different types in different context, it was hard to know what was what. This is part of the cleanup work.
The updated SMB abstraction layer supports skipping the NetBIOS protol layer altogether, which improves compatibility with Windows Vista, Windows 7, etc.
- It appears that Windows XP can produce directory listings with
file/directory modification times set to 0, indicating that no
such information is available, while the associated last file
write access data is present. Previously, smbfs only reported
the modification. If this data is unavailable and the date of
the last write access is, the last write access will be
reported instead.
git-svn-id: file:///Users/olsen/Code/migration-svn-zu-git/logical-line-staging/amiga-smbfs/trunk@11 26594b9e-b914-4e86-b7a1-9402bd427170
- Replaced the long NT date conversion code with something hopefully
much more robust. The results so far are both encouraging and
irritating. Dates that previously came out as "unknown" are now
processed, but there are differences between the dates shown in the
directory listing and by listing the files by name. Go figure...
- Transplanted some more code from Samba to handle directory entry
data conversion.
git-svn-id: file:///Users/olsen/Code/migration-svn-zu-git/logical-line-staging/amiga-smbfs/trunk@5 26594b9e-b914-4e86-b7a1-9402bd427170
Olaf Barthel
Tygre
obarthel