Workaround for NTFS returning resume keys of zero.
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'
Showing with 255 additions and 238 deletions