Hi Franz,

On Aug  2 16:26, Franz Sirl wrote:
> Am 2016-07-29 um 16:38 schrieb Corinna Vinschen:
> > On Jul 29 16:18, Corinna Vinschen wrote:
> > > In the first place it would be prudent to find out why the
> > > FileAllInformation info class fails on this drive.  And in the second
> > > place it would be important to find out how to fix this.  Potential
> > > checks:
> > > 
> > > - Buffer alignment of the FILE_ALL_INFORMATION member in class
> > >   path_conv_handle.
> > > 
> > > - Buffer size of the FILE_ALL_INFORMATION member.  For instance,
> > >   does it work if the buffer is 1 byte bigger?  Or perhaps if
> > >   the buffer is NAME_MAX bigger?
> > 
> > - There's also a chance (albeit minor) that the FileAllInformation call
> >   actually worked and the weird status code is just wrong.  After all,
> >   returning from this call with STATUS_BUFFER_OVERFLOW is valid, too,
> >   so I'd check for this as well here.
> 
> Hi Corinna,
> 
> no, the error code isn't influenced by alignment or size. For local drives
> and SMB shares the STATUS_BUFFER_OVERFLOW turns into STATUS_SUCCESS as soon
> as there is enough room for the share path in the
> FILE_NAME_INFORMATION.FileName flexible array member (actually, why isn't
> path_conv_handle.attribs._fai larger? performance? FileNameInformation
> usually not needed?).

FileNameInformation is the full path to the file.  It's not only not
needed, but for full long pathname support the buffer would have to
be sizeof (FILE_ALL_INFORMATION) + 32767 * sizeof (WCHAR), thus more
than 64K in size.

FileAllInformation is designed so that you can ask for all information
except the filename by just ignoring the name buffer requirements.  In
that case NtQueryInformationFile returns STATUS_BUFFER_OVERFLOW, which
can be ignored.

> But for the NCP share the strange error code for
> FileAllInformation remains. Checking all the members of FileAllInformation
> one by one, it turned out that it's the FileInternalIformation member that
> fails. I've reported it as a bug to Novell.

Cool.  NtQueryInformationFile is supposed to just set all unsupported
members to 0, see the Remarks section of
https://msdn.microsoft.com/en-us/library/windows/hardware/ff567052(v=vs.85).aspx

However, do we need a workaround?  Kind of like this:

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 970a0fe..d9ed357 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -1307,6 +1307,19 @@ file_get_fai (HANDLE h, PFILE_ALL_INFORMATION pfai)
                                   FileAllInformation);
   if (status == STATUS_BUFFER_OVERFLOW)
     status = STATUS_SUCCESS;
+  /* Filesystems with broken FileAllInformation exist, too.  See the thread
+     starting with https://cygwin.com/ml/cygwin/2016-07/msg00350.html. */
+  else if (!NT_SUCCESS (status) && status != STATUS_ACCESS_DENIED)
+    {
+      memset (pfai, 0, sizeof *pfai);
+      status = NtQueryInformationFile (h, &io, &pfai->BasicInformation,
+                                      sizeof pfai->BasicInformation,
+                                      FileBasicInformation);
+      if (NT_SUCCESS (status))
+       status = NtQueryInformationFile (h, &io, &pfai->StandardInformation,
+                                        sizeof pfai->StandardInformation,
+                                        FileStandardInformation);
+    }
   return status;
 }
 

> Nevertheless I believe the fallback to
> NtQueryDirectoryFile(FileIdBothDirectoryInformation) does not do what you
> want if the path is the root directory of a share. But that's not the cause
> of this problem.

Yeah, as I wrote in my reply, the NtQueryDirectoryFile branch isn't
supposed to be hit in this scenario.  It's solely for "access denied"
situations.

Are you set up to build your own Cygwin DLL so you can test the above
patch locally?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature

Reply via email to