DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=f3UJ84egoGlybI/i
	PkA9e9IzggEoXZCYdITp6O+w/dL70DHxvznk7nmiMqltCEt+2ufeyz7x4jfZenTh
	6g6nbGZl8koLDj8LbwZq6Fa9cWpTXrOHXlRfOFZrBEx/K7zFIeqQTFhPCDDMXXrm
	suEqKmbUyQ/13RRH5by/5i/jMX8=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Subject: Re: Size limitation for NcFsd drive?
To: cygwin@cygwin.com
References: <2483665a-eae1-737d-59f2-ca6af9428aca@lauterbach.com> <2b6c3324-0a18-7437-c85b-bb30d3cbdbae@lauterbach.com> <20160728195859.GE26311@calimero.vinschen.de> <8ffdb11a-a2a6-109b-988d-2d5f38c98731@lauterbach.com> <20160729141831.GA9364@calimero.vinschen.de> <20160729143815.GE5963@calimero.vinschen.de>
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
Message-ID: <dc4405e7-94c8-b24d-71ea-2359578fc30b@lauterbach.com>
Date: Tue, 2 Aug 2016 16:26:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Thunderbird/47.0
MIME-Version: 1.0
In-Reply-To: <20160729143815.GE5963@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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?). 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.

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.

Franz.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple