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
signature.asc
Description: PGP signature
