FileZerver release V04.16.00 is now available for download for firmware update of Cyclone 2+ boards using the admin "Firmware Update" web page or FTP, in file fzi0416.bin. Changes -- The major change with V04.16 is that the code for "Windows Network Protocols" known as "CIFS - Common Internet File System" has been upgraded. Project Samba (named for "SMB - Service Message Blocks", an earlier name for the protocol) is now samba-3.0.21c from February 2006. (Previous releases had used samba-3.0.11.) This was prompted largely by problems encountered when a FileZerver had been joined to a Windows Domain as run by a Windows-2003 server. When SP1 - Service Pack 1 was applied to the server, some number of Windows security holes may have been patched, and something was broken with interactions with the FileZerver. Those problems should be fixed with this release. Some configuration changes have been made in how samba operates within a FileZerver. These are intended to have the effect that file-permissions will behave closer to what a DOS user would expect (such as delete of a read-only file, which should be deleted without complaint), and less-close to what a unix user would expect (who would expect a delete of a read-only file to lead to an "Are you sure?" prompt). SmartMirror operations have been changed in several ways. -- The number of scheduled tasks, SmartMirror and Tape-Backup, can now be 45 (had been 40). -- Added two new SmartMirror task-types -- "Pull by Directory Rename" and "Delete Local and Pull by Directory Rename", which are intended to use a quick Rename operation where an expensive local copy operation might have been used instead. These values join the list set by "Direction" -- "Pull from Remote Server", "Pull from Remote, Newer Files Only", "Push to Remote Server", "Push to Remote, Newer Files Only". A more complete description is included below. -- Even with the "Rename" operations, there are times, within a chain of SmartMirror tasks, when a directory and its subordinate files must be copied to another location within the same system. SmartMirror tasks have used the "localhost" IP Address, "127.0.0.1", which makes a client-server connection using the loopback pseudo-device. This works well, but involves both a client-task and a server-task on the same system. A change implemented in this release will recognize a variation of the "localhost" IP Address, "127.0.0.0", as the trigger to let the rsync task (which is the program which does all the heavy lifting for SmartMirror) read and write all the files directly, rather than using a TCP connection to a separate server task. This should provide performance benefits, but there could be subtle differences involving permissions and ownership, and so this optimization is only applied when the exact localhost IP Address "127.0.0.0" is specified. -- Within a chain of SmartMirror tasks, if a step ends with return code 23 (sometimes displayed as hexadecimal code 0x17), for "Partial Transfer, one or more files had problems", or return code 24 (sometimes shown as hex 0x18) for "File Vanished before transfer", those codes are now treated as warn-conditions (rather than fatal conditions), and the chain of SmartMirror tasks can continue. -- SmartMirror changes made in version V04.15b (which was not widely available) for the SmartMirror server program -- The timeout value was changed to accomodate million-entry file lists to 72000 seconds, 20 hours (had been 7200 seconds, 2 hours). Also, SmartMirror server-side log messages are now sent to syslog (previously they had been discarded). Directory Rename This explanation of the SmartMirror Directory Rename operations has been adapted from the Help text. Direction choices "Delete Local and Pull by Directory Rename" and "Pull by Directory Rename" were created for use within an elaborate chain of SmartMirror tasks that can be used to manage a time-sequence of directories, such as when directories named "Week1", "Week2", etc. hold copies of a repository of files and folders as it existed one week ago, two weeks ago, etc. SmartMirror tasks using these direction selections require that the "IP Address" of the "Remote Server Settings" be "127.0.0.1", which is a special IP address generally known as "localhost". On all systems, it addresses the "loopback" pseudo-device, and is thus an IP address by which a node can address itself. Therefore the entries under "Remote Server Settings" for "Share" and for "Path in Share" are not located on some remote system somewhere, but are on the same system with "Local Settings" entries for "Share" and "Path in Share". In order for a directory-rename operation to work, the directories thus identified must be within the same Raid Group, and the expected use is that these will be two directories within a common container directory. A SmartMirror task defined with a Direction value of "Delete Local and Pull by Directory Rename" will perform serveral steps. (1) The directory identified under "Local Settings" by the entries for "Share" and for "Path in Share" will be deleted, including all subdirectories, folders, and files. (2) A rename will be done for the (local) directory identified under "Remote Server Settings" by entries for "Share" and "Path in Share" to use the name of the just-deleted directory given by "Local Settings". (3) An empty directory will be created using the just-abandoned name given by the "Remote Server Settings". For example, for an environment in which the state of a repository is captured every week and kept for four weeks, the Local Settings might select Share "ARCHIVE" Path in Share "Week4" within a task with Direction "Delete Local and Pull by Directory Rename" which would delete directory "Week4" containing files more than four weeks old. If Remote Server Settings (with IP Address of "127.0.0.1") selected Share "ARCHIVE" and Path in Share "Week3", then directory "Week3", holding files more than three weeks old, would be renamed and become directory "Week4". An empty directory named "Week3" is then created. The effect is that all of the files, folders, and subdirectories that had been within "Week3" are now within "Week4", files older than four weeks are gone, and this has been achieved without having to do a copy-operation. A SmartMirror task defined with a Direction value of "Pull by Directory Rename" differs from the above in that the target directory defined by "Local Settings" for "Share" and "Path in Share" must be empty (or not exist at all) -- a delete of any and all files, folders, and subdirectories is not done. For example, if directory "Week3" is known to be empty (as it would be after the previous example), then a SmartMirror task with Direction "Pull by Directory Rename" could have Local Settings of Share "ARCHIVE" Path in Share "Week3". If directory "Week2" had files which were more than two weeks old, then the task would have Remote Server Settings (with IP Address of "127.0.0.1") of Share "ARCHIVE" and Path in Share of "Week2". The effect will be that the files and folders that had been within directory "Week2" will suddenly be found in directory "Week3". An empty directory named "Week2" will be created so that there can be a chain of these tasks. If a SmartMirror task with Direction "Pull by Directory Rename" encounters a non-empty target directory, then something has gone wrong and the task ends with error message "Directory is not empty" to be found in the syslog. Because both directories are to be found on the local system, the entries for "Login Name" and "Password" within "Remote Server Settings" are not used. March 29, 2006