GitLab

Detail:
  When the underlying FS is NTFS, eg. WinXP Pro, the requested
  resume keys for a directory search are always zero - this is passed
  back via OSGBPB and on the next call it triggers a new search. So
  we get stuck in an infinite loop.
  Now checks for a resume key stuck at zero, and makes a fake one static
  to the search context then sets the continuation bit in the SMB_FIND_NEXT
  call because the server returning the duff key remembers the position.
  Dir_CallbackFn could return with "taken" undefined. Move a few lines
  higher.
  Missing "#else" added to CHECK_ARMBOOT_EXISTS so if this is disabled
  no further attempt is made to find !ArmBoot.
  Couple of typos corrected.
  Spelling of "disk" changed to "disc" in an error message.
Admin:
  Tested with XP Pro SP3 with NTFS, directories which previously hung
  the filer now open correctly. Checked with XP Home SP3 with FAT32 to
  verify behaviour unchanged from 2.32.
  Note, with large directories the initial path translation triggers a
  dir search too which takes ages compared with the actual number of
  entries returned. This could be cached to make counting far faster.

Version 2.33. Tagged as 'LanManFS-2_33'

Directory rename fixed - the mask being passed by the rename routine didn't have the ATTR_DIR bit set.Discovered this after reading lots of the spec which is also now included here in /doc.

Copying files out of LanManFS filer "forgot" their filetype even though
they appeared right in the filer,fixed.
A stray debugging printf removed,along with one compiler warning.
New sprites (yuck) to match !Omni.
Reordered the shutdown in two places,first Omni_Shutdown bins the mounts
lists which SMB_Shutdown uses.Second in NetBEUI mode the announcement that
a protocol has terminated goes *after* the shutdown - otherwise you sit
around for about 20s wondering where the link has gone.

Version 2.25. Tagged as 'LanManFS-2_25'

Detail:
  The module used to have specific knowledge of the driver to which it
    was supposed to bind if it was unable to find any active drivers at
    the time that LanManFS was initialised.  This meant that if the
    LanManFS module was placed in ROM (eg. in STB3) and the drivers
    hadn't initialised by the time that LanManFS was initialised, it
    would sit and wait for EtherH to arrive - which doesn't happen
    for ATM solutions, and doesn't happen for Ethernet in STB3 because
    we no longer use EtherH!
Admin:
  Tested in STB22 expansion cards, and in STB3 ROM builds for both
    Ethernet and ATM solutions.

Version 2.05. Tagged as 'LanManFS-2_05'

  Introduced new error message for re-entrancy prevention trap to use.
Detail:
  When 'pinging' an SMB server, LanManFS does not wait for any response
    but the response reading routine knows to just throw away any old
    SMBchkpth responses that it gets and try reading again.
  Re-entrancy trap now has its own error "LanManFS in use" &1663E, which
    means you no longer see "!Armboot files nested too deeply" which is
    confusing.  The only way you can provoke this message is if you use
    Alt-Break whilst the NetBIOS/IP code is executing.  The error plays
    the same part as "FileCore in use" does for FileCore.
Admin:
  Verified module still works and the anti idle-out features still work.

Version 2.04. Tagged as 'LanManFS-2_04'

RiscOS/Sources/Networking/LanManFS is now locked out.

The rest of Omni will be imported at a later date.

Version 1.87, tagged as LanManFS-1_87