This is the mail archive of the
mailing list for the Cygwin project.
Re: Size limitation for NcFsd drive?
Am 2016-07-28 um 21:58 schrieb Corinna Vinschen:
On Jul 28 17:33, Franz Sirl wrote:
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
$ ls -l /cygdrive/
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
$ ls -ld /cygdrive/t/.
ls: cannot access '/cygdrive/t/.': Not a directory
$ 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.
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
RtlSplitUnicodePath (&upath, &dirname, &basename);
status = NtQueryDirectoryFile (dir, NULL, NULL, NULL,
&fdi_buf, sizeof fdi_buf,
TRUE, &basename, TRUE);
/* Take the opportunity to check file system while we're
having the handle to the parent dir. */
fs.update (&upath, 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/ =
42 764638 [main] ls 7456 mount_info::conv_to_win32_path:
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
316 765465 [main] ls 7456 symlink_info::check: 0xC7E90006 =
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
Does anyone know if the NtQueryDirectoryFile() spec makes any guarantees
the order of the returned entries?
And, as an explanation, this happened because during the copying of this
the filesystem was changed from pure ext3 to ext3 with dir_index
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
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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple