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.
Added const qualifiers to the parameters used by the functions in "crypt.c". This in turn revealed that the smb_encrypt() function did not in fact modify the password string passed to it, which allowed the smb_proc_reconnect() function in "proc.c" to be simplified.
Augmented the file handle, file lock and SMB file access operations with splay trees to improve performance for validation and lookup. Instead of having to walk the entire list of file, lock or SMB file entries, comparing the list entries by name or address, the entire process should have to check 1-5 entries only.
This splay tree functionality is a compile time option which has to be enabled in the "splay.h" header file.
If there is a port number given as part of the share name which is out of range, smbfs now reports this as a specific error rather than just stating that the service is not valid.
Replaced duplicate code in "smb_abstraction.c" which built path names from a parent directory name and a file/directory name with a single common solution.
Revised the build makefiles to create the standard smbfs variant rather than the one with full debugging support enabled. The AmigaOS4 variant specifically avoids using cross-compilation options which would have to be enabled first, if needed.
Added the ADDVOLUME option, which defaults to "yes". If no volume name is
provided, smbfs will use the service name as the template, e.g. if you
connect to //server-name/pictures then the default volume name will
be "pictures". The idea is that if the file server allows this, you
should not need to start the smbfs program with any parameter other
than the service/share name and it should work out of the box.
Preparations for showing error messages when running as a Workbench
program would corrupt memory once the message was ready for display,
but this only happened in the AmigaOS4 build. As far as I can tell
this never worked correctly on AmigaOS4. Thanks go to Matthew Kille
who reported the problem!
Simplified the icon parameter processing used when running smbfs
as a Workbench program. The reworked code is now basically limited
to processing and setting up the same configuration data which the
shell command use employs. Both paths share the same configuration
data checking and handling.
Turns out that the ACTION_CURRENT_VOLUME function does need to return
the volume node, not the device node. Note to self: a 'struct DeviceList'
refers to a volume (DLT_VOLUME), whereas a 'struct DeviceNode' refers
to a device (DLT_DEVICE). See? This could have been easily been avoided :-/
Added more code documentation, especially for the various constants and
data structures defined and used in "main.c".
Reading from the file name translation file now performs better error
detection and reporting. If read errors should crop up, the error message
will now say so. If the file is shorter than required the error message
will reflect this.
Reworked the smb_proc_reconnect() function so that it does not end up
truncating the password before it is encrypted. This means that up to
63 characters of the password can be used to produce the encrypted
form, resolving problems with longer server passwords not quite
matching what you entered. However, since this long encrypted password
is still accompanied by the legacy encrypted form which truncates the
password to 14 characters (which are converted to all-upper-case
letters) there is no actual gain in terms of security...
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.
You can now choose which type of information should be reported, and how many entries should be returned.
These options provide even more control over the behaviour of the ExAll() function, as well as exercising the ExAllEnd() function.
In case the program should end up looping (e.g. more != FALSE and control->eac_Entries == 0) you can now abort it with Ctrl+C. Note that API documentation for ExAll() as well as the corresponding example code only state that if control->eac_Entries == 0 more is *usually* FALSE. There is a loophole here...
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.
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.
obarthel
Olaf Barthel