82277 packages online


No screenshot available
Short:SMB file system client (BETA version)
Author:Olaf Barthel (obarthel at gmx dot net)
Uploader:Renaud Schweingruber (renaud schweingruber gmail com)
Requires:Miami, Miami Deluxe, AmiTCP 3.x, AmiTCP Genesis or Roadshow
Download: - View contents
[ Note from Aminet administrator: This is a beta version containing at least ]
[ one known bug, use at your own risk. Olaf Barthel will release a stable    ]
[ version when it's done.                                                    ]

SMBFS 1.117 - 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.

This build is a simple binary compile from source code found on

ChangeLog (after 1.102 release from :

smbfs 1.103 (14.4.2016)

- Added DUMPSMBLEVEL option which controls how much raw
  data output is produced. By default (level 0) no raw
  data output is produced at all. Level 1 will print the
  contents of the command data area. Level 2 will print
  the raw data used by the respective commands, with any
  management/control information stripped off.

smbfs 1.104 (16.4.2016)

- For smb_request_write_raw() return values of 0 now indicate success.

- Simplified the raw read portion of smba_read() by removing the test
  that avoids dropping into a read loop below. The loop handles the
  special case well.
- Recalculated the overhead for SMB_COM_READ. It's still 52 bytes,
  but now the documentation states how this number comes about.
- Recalculated the overhead for SMB_COM_WRITE. It's 52 bytes and
  not 56 bytes.

- Recalculated the overhead for the SMB_COM_WRITE_RAW command, and
  it's 63 bytes, not 4.

- Unless smb_proc_write_raw() finds that sending the packet results
  in a transmission error, it will try to pick up the server responses.
  Previously, it would not even try that, which could deadlock the
  client<->server message exchange.

smbfs 1.105 (16.4.2016)

- 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.

smbfs 1.106 (17.4.2016)

- More detailed error class/code translation information now
  shows up in the debug log.

- The SMB dump output can now be stored in a file, rather than
  having to be redirected to one. When storing it in a file,
  the output will be appended to an existing file, otherwise
  a new file will be created.

- The raw read/write functions now respect the upper limit
  for the amount of data to be written, as given by the server.

smbfs 1.107 (20.4.2016)

  allow SMB_COM_WRITE_RAW commands to complete asynchronously.
  PREFERWRITERAW will make the file system use SMB_COM_WRITE_RAW
  over SMB_COM_WRITE when it has a choice.

smbfs 1.108 (23.4.2016)

- Now properly handles the error code returned when Samba
  is asked to remove a non-empty directory. The error is
  translated to ENOTEMPTY.

smbfs 1.109 (23.4.2016)

- Activated the PREFERWRITERAW option which had not been wired
  up yet. Oops :-(  Turns out that with this option enabled
  write operations are indeed slower than the with the
  adaptive SMB_COM_WRITE/SMB_COM_WRITE_RAW code, on account that
  that SMB_COM_WRITE_RAW transmits the data in two packets, plus
  overhead for the server response.

- Recalculated the threshold below which a write operation will
  be performed using SMB_COM_WRITE instead of SMB_COM_WRITE_RAW.

- Fixed how the WRITEBEHIND option for the SMB_COM_WRITE_RAW
  command is implemented: the client must not wait for the
  server to acknowledge the command.

- Investigated the performance difference between SMB_COM_WRITE_RAW
  using the "write behind" and "write through" modes. In my tests
  the difference came down to about 10% performance gain for
  the "write behind" mode.

- Compared the performance of plain SMB_COM_WRITE (Windows 7) and
  the adaptive SMB_COM_WRITE/SMB_COM_WRITE_RAW (Samba 3.0.25).
  The adaptive SMB_COM_WRITE/SMB_COM_WRITE_RAW is about as fast
  as the plain SMB_COM_WRITE, with "Windows 7" running on the
  same machine as WinUAE (with AmigaOS 3.9) and Samba running
  on a local server connected via GBit Ethernet. This means that
  SMB_COM_WRITE is significantly slower with Windows 7.

smbfs 1.110 (1.5.2016)

- Added the DEBUGFILE/K option. Not everybody has Sashimi or
  a tool like it running in the background, which makes sharing
  file system level debug information difficult.

smbfs 1.111 (11.5.2016)

- You can now identify smbfs by checking the
DosList->dol_misc.dol_volume.dol_DiskType   field. It will read back as
0x534D4200, which is equivalent to the signature   "SMB\0". This change was
suggested by Chris Handley and Chris Young.
  Thank you very much!

smbfs 1.112 (26.9.2016)

- The negotiation in smb_proc_reconnect() picked up the server's
  maximum buffer size and then always added 4 bytes on top of it.
  From the looks of it, this was intended to account for the
  4 byte NetBIOS session header to be prepended to each SMB
  command block. In practice it could push the size of a
  write operation beyond what the server would accept.

smbfs 1.113 (29.9.2016)

- Removed the SMB_HEADER_LEN constant, since it wasn't actually referring to the
  length of the SMB header, but the NetBIOS session header plus the SMB header.
  This led to some confusion as to what exactly the packet byte offsets used by
  "proc.c" would reference.

- "proc.c" now lists the byte offset values into the packet buffer, so as
  to make it clearer what exactly is being referenced.

- smb_valid_packet() now correctly displays the expected and actual
  packet size.

- smb_setup_header() no longer includes the NetBIOS session header
  in the total message length calculation. Which means that smbfs
  no longer sends packets with a NetBIOS header which claims that
  the messages should be longer than they actually are.

- smb_proc_write_raw() no longer cares about the number of
  command words, but only about the number of data bytes and
  the command, when waiting for a raw write operation to

smbfs 1.114 (1.10.2016)

- The packet buffer size is now increased during the protocol
  negotiation, if the default buffer size proves to be too
  small. This avoids trouble with the MAXTRANSMIT option,
  which used to leave the original packet buffer size
  unchanged, and too short.

- The raw write operation no longer stumbles into a 0 length
  write, which the server would not expect and not respond to.

- Moved the test for the "write behind" option in the
  raw write operation so that it is handled before the
  server response (which hasn't arrived yet) is checked.

- Verified that the raw write operation can deal properly
  with the server response (interim update and write

smbfs 1.115 (2.10.2016)

- The MAXTRANSMIT option controls how much data smbfs is
  prepared to receive. That value cannot be smaller than
  8000 bytes, and it cannot be larger than 65535. The
  code which sets up this parameter and verifies that it
  is in range is now implemented only once, and not
  twice in different places.

- The MAXTRANSMIT option also controls how much data
  smbfs may send to the server. This limit is no longer
  capped at 65535 bytes.

- The size of the message reception/transmission buffer
  can no longer be smaller than 8000 bytes and it cannot
  be smaller than the number of bytes which may be sent
  to the server.

smbfs 1.116 (3.10.2016)

- smb_receive_trans2() now verifies that the amount of
  data received is not larger than the maximum acceptable
  by the client. Previously, it compared the amount of
  data received against the server's upper limit. Ouch :-(

- smba_readdir() now stops immediately if no directory
  entries are supplied. Previously, it could deliver
  a bogus directory entry to the scanning function.

- The number of directory entries accepted by smb_proc_readdir_short()
  is now calculated according to how much data the client will
  accept, and not according to the server's limit.

- smb_proc_readdir_long() now reports how much data the
  client will accept, rather than how much the server will
  accept. This was problematic because that number is a
  16 bit value, and the server's maximum transmission
  value could be larger than 65535 bytes, causing directory
  scanning to fail because the truncated 16 bit value
  could be too tiny to report even a single result.

smbfs 1.117 (11.4.2018)

- Looks like the SMB_COM_WRITE_RAW implementation is really as simple
  as the documentation suggested. Just two packets need to be sent to
  to the server.

Contents of comm/tcp/smbfs-68k_1.117.lha
---------- ----------- ------- ------- ------ ---------- ------------ ----------
[unknown]                93097  206764  45.0% -lh5- 4e70 Jan  1  1980 smbfs-68k_1.117
[unknown]                 3797    9280  40.9% -lh5- 2325 Apr 24 22:08 smbfs-68k_1.117.readme
---------- ----------- ------- ------- ------ ---------- ------------ ----------
 Total         2 files   96894  216044  44.8%            Apr 24 17:17

Aminet © 1992-2018 Urban Müller and the Aminet team. Aminet contact address: <aminetaminet net>