Short: SMB file system client; complements Samba Author: Olaf Barthel (olsen@sourcery.han.de) Uploader: Varthall / Up Rough (varthall01 gmail com) Type: comm/tcp Version: 1.74 Replaces: comm/tcp/smbfs.lha Requires: Miami, Miami Deluxe, AmiTCP 3.x or AmiTCP Genesis Architecture: m68k-amigaos SMBFS 1.74 - A SMB file system wrapper for AmigaOS, using the AmiTCP V3 API =========================================================================== SMBFS implements an SMB file system for AmigaOS. This file system can be used to access files made available by file servers which implement the SMB protocol, such as 'Microsoft Windows' or any other platform which supports the free 'Samba' product. These files can be accessed using shell commands such as 'List', the Workbench or utilities such as 'Directory Opus' as if the file server were a local disk drive. Changelog (starting from the previously released 1.66 version): smbfs 1.74 (31.8.2009) - Integrated Harry Sintonen's fix for the problem caused by large writes to files. The respective packet size was off by one byte. Thank you very much! smbfs 1.73 (17.4.2009) - Modified smb_valid_packet() in proc.c to check whether the packet received is smaller than expected, not whether the length matches exactly. This seems to fix the protocol negotiation with Samba 3.2.5 for now. Haven't checked Vista yet, though... smbfs 1.72 (14.4.2009) - 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. smbfs 1.71 (13.6.2005) - The extended directory scanning entry conversion code now swaps the last modification and last write access date stamps. This matches the time of the last modification, as returned by the regular ACTION_EXAMINE_FH/ACTION_EXAMINE packets. Note that the time resolution is a little bit coarser because the modification time as expressed by the SMB getattr function cannot represent 60 distinct seconds per minute but only 30. The net effect is that the resulting time stamps in a directory listing and by examining a file can differ by one second. - The DST option's time offset was added to rather than subtracted from the local time. Fixed. smbfs 1.70 (13.6.2005) - Introduced a new option to account for daylight savings time when appropriate. - Looks like some of the time stamps used in "proc.c" are transmitted in local time after all; brought back the conversion functions. smbfs 1.69 (13.6.2005) - The time stamps used in "proc.c", as returned and submitted to the SMB file system on the other end of the wire are apparently all in Universally Coordinated Time already (or at least, this seems to be the case with Samba and Windows XP). Hence no conversion between local time and UTC is necessary, which would otherwise distort all date stamps converted. I modified the file system to leave all time stamps essentially unadjusted for local time in "proc.c". The local time zone adjustments are now performed only where the time in question is known to be Amiga-specific, such as the current system time or the date stamp to set for a file. The time conversion appears to be working correctly now, but it does ignore the effects of daylight savings time, which you might want to adjust for manually through the TIMEZONEOFFSET option (careful though: this overrides your current locale-defined time zone settings as far as smbfs is concerned). Unsolved problem: at least Windows XP seems to return different time stamps for directory listings and for indidivual files. As far as I can tell, the sets of time stamps returned for either doesn't match anywhere. smbfs 1.68 (3.6.2005) - 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. smbfs 1.67 (27.5.2005) - 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.