• Robert Sprowson's avatar
    Workaround for NTFS returning resume keys of zero. · d1ca5496
    Robert Sprowson authored
    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'
    d1ca5496
CoreFn 25.6 KB