This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Size limitation for NcFsd drive?


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@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@FRAPC4 ~
$ ls -ld /cygdrive/t/.
ls: cannot access '/cygdrive/t/.': Not a directory

fsirl@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]