NtOpenFile/IopCreateFile opens incorrect File Object when called with only a handle on original FAT driver.

replacement of older FAT driver resolved this - (but failure may still be present in older driver)

When NtOpenFile is called to 'reopen' a file using only the handle from a prior successful NtOpenFile call based on the path, the resulting call to IopCreateFile returns Success and a Handle, but does not open the correct file. This sequence has some specific dependencies including not sharing the same structures in the two NtOpenFile calls, but the first call opens the file properly, the second call opens the host volume when using the original FAT driver. The actual fault appears to be in the io manager file.c file. I have attached a test that can be added to ntdll_apitests to show the failure conditions. The root of the problem seems to be that IopCreateFile always attempts a name lookup even when a name is not present. I have also attached a patch that can be inserted into IopCreateFile just after it performs file validations that appears to resolve the problem. I am not a C programmer or Kernel programmer so the code is very preliminary but does build and work. the test was originally created by learn_more and has been patched to highlight this issue. Note this does not seem to occur with BtrFs and has not been tested with the ported MS FAT driver (yet).