delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2016/07/29/09:26:10

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=xVgyMxXHfvRjxNhT
wEWGtU7Y/WL/aPXbk2qDS4BFQvKIvyzaSsaRlt8U64uXsfE0/Pn/8TbsPYGHYqgI
CnAQQHGwDx2hlTycxwnEUueryZyB5sv/F0dpck3OjhZzSHbh0+rS04C0qRdRwJVj
57ngat8fVQkvbhGX+22JCUW35a4=
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=gpi01JHFVXDFarZAPiDy76
G0IlM=; b=qaJUvHrfk0P/AoCi8I1gHIeNkK7nNe0urrBV5ZWkuIYfkA2ni8kj9y
KYQEIJYzw3gnyjsLF1TqzVTWVl6bRvzHGb/zWgzuNLiELiyvS8vfyUH8A4qOXzf1
er71tJOe/WRg0Q2QITmVbjB3NFhMbSZIsEEJE1mGkAfXc5rusJkVg=
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.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=2800, H*M:988d, H*M:109b, 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.465305 secs); 29 Jul 2016 13:25:46 -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>
From: Franz Sirl <Franz DOT Sirl-kernel AT lauterbach DOT com>
Message-ID: <8ffdb11a-a2a6-109b-988d-2d5f38c98731@lauterbach.com>
Date: Fri, 29 Jul 2016 15:25:40 +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: <20160728195859.GE26311@calimero.vinschen.de>
X-IsSubscribed: yes

Am 2016-07-28 um 21:58 schrieb Corinna Vinschen:
> On Jul 28 17:33, Franz Sirl wrote:
>> Hi,
>>
>> some more hints. A colleague reported it still works with Cygwin-2.0.4. And
>> for some reason only the toplevel doesn't work (seems it's not detected as a
>> directory):
>>
>> fsirl AT FRAPC4 ~
>> $ ls -l /cygdrive/
>> total 87
>> d---r-x---+ 1 NT SERVICE+TrustedInstaller NT SERVICE+TrustedInstaller  0 Jul
>> 28 15:06 c
>> drwxrwx---+ 1 SYSTEM                      SYSTEM  0 Jul 20 12:43 d
>> drwxr-xr-x  1 fsirl                       Domain Users  0 Aug  2  2011 f
>> drwxr-xr-x  1 fsirl                       Domain Users  0 Jan 12  2016 g
>> drwxr-xr-x  1 fsirl                       Domain Users  0 Mrz 27  2015 h
>> drwxr-xr-x  1 fsirl                       Domain Users  0 Dez 15  2014 i
>> drwxr-xr-x  1 fsirl                       Domain Users  0 Jun 30 08:05 j
>> drwxr-xr-x  1 fsirl                       Domain Users  0 Jul 28 15:01 l
>> drwxr-xr-x  1 fsirl                       DE  0 Jul 28 14:38 n
>> -rw-r--r--  1 fsirl                       Domain Users 67948 Jul 25 19:53 t
>>
>> fsirl AT FRAPC4 ~
>> $ ls -ld /cygdrive/t/.
>> ls: cannot access '/cygdrive/t/.': Not a directory
>>
>> fsirl AT FRAPC4 ~
>> $ ls -ld /cygdrive/t/dvd-branch/.
>> drwxr-xr-x 1 fsirl Domain Users 0 Jun 11 01:08 /cygdrive/t/dvd-branch/.
> Could it be permissions?  Can you send the output of `icacls T:'?
>
> Other than that, an strace of `ls -ld /cygdrive/t/.' might give a clue.

Hi Corinna,

no, it's not permissions, it's the order in which files are returned for
directory enumeration. There is this code snippet around line ~2800 in 
path.cc:

                   RtlSplitUnicodePath (&upath, &dirname, &basename);
....
                   status = NtQueryDirectoryFile (dir, NULL, NULL, NULL, 
&io,
&fdi_buf, sizeof fdi_buf,
FileIdBothDirectoryInformation,
                                                  TRUE, &basename, TRUE);
                   /* Take the opportunity to check file system while we're
                      having the handle to the parent dir. */
                   fs.update (&upath, dir);
                   NtClose (dir);

It tries to query the first entry returned and assumes (no idea if Windows
guarantees that, POSIX does not AFAIK) that it is ".". But in my case for
this drive it is just some file that happens to be first in the directory
enumeration. And then everything goes wrong from there.

The related strace excerpt shows:

  1788  764507 [main] ls 7456 lstat64: entering
    45  764552 [main] ls 7456 normalize_posix_path: src /cygdrive/t/.
    44  764596 [main] ls 7456 normalize_posix_path: /cygdrive/t/ = 
normalize_posix_path (/cygdrive/t/.)
    42  764638 [main] ls 7456 mount_info::conv_to_win32_path: 
conv_to_win32_path (/cygdrive/t)
    49  764687 [main] ls 7456 mount_info::cygdrive_win32_path: src 
'/cygdrive/t', dst 'T:\'
    46  764733 [main] ls 7456 set_flags: flags: binary (0x2)
    44  764777 [main] ls 7456 mount_info::conv_to_win32_path: src_path 
/cygdrive/t, dst T:\, flags 0x4022, rc 0
   372  765149 [main] ls 7456 symlink_info::check: 0x0 = NtCreateFile 
(\??\T:\)
   316  765465 [main] ls 7456 symlink_info::check: 0xC7E90006 = 
NtQueryInformationFile (\??\T:\)
  1573  767038 [main] ls 7456 symlink_info::check: not a symlink
    64  767102 [main] ls 7456 symlink_info::check: 0 = 
symlink.check(T:\, 0xFFFFB6E0) (0x404022)
    65  767167 [main] ls 7456 path_conv::check: T:\ is a non-directory
    44  767211 [main] ls 7456 stat_worker: got 20 error from path_conv
    43  767254 [main] ls 7456 __set_errno: int stat_worker(path_conv&, 
stat*):1857 setting errno 20
    54  767308 [main] ls 7456 stat_worker: -1 = (\??\T:\,0x60004AC40)

So upath was likely "\??\T:\" and I guess RtlSplitUnicodePath() returned
"" or "*.*" for basename.
Maybe a possible fix/workaround would be to force basename to "." in 
this case?
Does anyone know if the NtQueryDirectoryFile() spec makes any guarantees 
about
the order of the returned entries?

And, as an explanation, this happened because during the copying of this 
share
the filesystem was changed from pure ext3 to ext3 with dir_index 
enabled. With
dir_index enabled the directory entries are enumerated in an order dictated
by the hashing I guess. I turned of the dir_index feature and Cygwin 
started
working normally again on this drive. But note that it only works because
now "a directory" is returned as first entry, but it seems it's usually not
"." with NcFsd. Seems like it worked by accident before.

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019