Size limitation for NcFsd drive?
Corinna Vinschen
corinna-cygwin@cygwin.com
Thu Aug 4 12:36:00 GMT 2016
Franz? Ping?
Thx,
Corinna
On Aug 2 16:59, Corinna Vinschen wrote:
> 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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20160804/14584a4f/attachment.sig>
More information about the Cygwin
mailing list