X-Recipient: archive-cygwin AT delorie DOT com
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=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; 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; s=default; bh=wg/EaLKFMChvFvbw0syY6z
	JqmeI=; b=f6PLlM+a5pxNJeH2oWxRFDX4alVPn+Ro/GGNj6LbLF4J7PX9Mtfp93
	mopjQmwNDIGtR/H+eQYXQhZutgSTOwqiXkqi+jFvFkxSaO00uI9UnvIf4/WzmEHd
	RbcY2lfrUaHUQBA0+S1hATR92hyaYz5o9/JldVu0vYXW4k1UwO2+w=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=NAME_MAX, name_max, H*r:envelope-sender
X-HELO: smtp1.lauterbach.com
X-Qmail-Scanner-Diagnostics: from 10.2.11.10 by smtp1.lauterbach.com (envelope-from <Franz DOT Sirl-kernel AT lauterbach DOT com>, uid 484) with qmail-scanner-2.11  (mhr: 1.0. clamdscan: 0.99/21437. spamassassin: 3.4.0.   Clear:RC:0(10.2.11.10):SA:0(-12.9/5.0):.  Processed in 5.308282 secs); 02 Aug 2016 14:26:48 -0000
Subject: Re: Size limitation for NcFsd drive?
To: cygwin AT cygwin DOT com
References: <2483665a-eae1-737d-59f2-ca6af9428aca AT lauterbach DOT com> <2b6c3324-0a18-7437-c85b-bb30d3cbdbae AT lauterbach DOT com> <20160728195859 DOT GE26311 AT calimero DOT vinschen DOT de> <8ffdb11a-a2a6-109b-988d-2d5f38c98731 AT lauterbach DOT com> <20160729141831 DOT GA9364 AT calimero DOT vinschen DOT de> <20160729143815 DOT GE5963 AT calimero DOT vinschen DOT de>
From: Franz Sirl <Franz DOT Sirl-kernel AT lauterbach DOT 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
X-IsSubscribed: yes

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