Size limitation for NcFsd drive?

Franz Sirl Franz.Sirl-kernel@lauterbach.com
Fri Jul 29 14:26:00 GMT 2016


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



More information about the Cygwin mailing list