delorie.com/archives/browse.cgi | search |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |