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'