Size limitation for NcFsd drive?

Size limitation for NcFsd drive?

[Franz Sirl]

Hi,

yesterday I enlarged one share of a OES-Server to 4.87TB. After that it 
seems
the drive mapped to this share is no longer properly visible in at least 
CygWin 2.5.[12]/2.6.0-0.3.
An old installation with 1.7.35 works still fine.

For T: (failing) and L: (ok, hosted on the same server) getVolInfo shows 
the following:

fsirl@FRAPC4 ~
$ /usr/lib/csih/getVolInfo.exe /cygdrive/t
Device Type        : 7
Characteristics    : 30
Volume Name        : <T32NEW>
Serial Number      : 1549022002
Max Filenamelength : 255
Filesystemname     : <NcFsd>
Flags              : a2
   FILE_CASE_SENSITIVE_SEARCH  : FALSE
   FILE_CASE_PRESERVED_NAMES   : TRUE
   FILE_UNICODE_ON_DISK        : FALSE
   FILE_PERSISTENT_ACLS        : FALSE
   FILE_FILE_COMPRESSION       : FALSE
   FILE_VOLUME_QUOTAS          : TRUE
   FILE_SUPPORTS_SPARSE_FILES  : FALSE
   FILE_SUPPORTS_REPARSE_POINTS: TRUE
   FILE_SUPPORTS_REMOTE_STORAGE: FALSE
   FILE_VOLUME_IS_COMPRESSED   : FALSE
   FILE_SUPPORTS_OBJECT_IDS    : FALSE
   FILE_SUPPORTS_ENCRYPTION    : FALSE
   FILE_NAMED_STREAMS          : FALSE
   FILE_READ_ONLY_VOLUME       : FALSE
   FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
   FILE_SUPPORTS_TRANSACTIONS  : FALSE

fsirl@FRAPC4 ~
$ /usr/lib/csih/getVolInfo.exe /cygdrive/l
Device Type        : 7
Characteristics    : 30
Volume Name        : <L_DRIVE>
Serial Number      : 1548508996
Max Filenamelength : 255
Filesystemname     : <NcFsd>
Flags              : a2
   FILE_CASE_SENSITIVE_SEARCH  : FALSE
   FILE_CASE_PRESERVED_NAMES   : TRUE
   FILE_UNICODE_ON_DISK        : FALSE
   FILE_PERSISTENT_ACLS        : FALSE
   FILE_FILE_COMPRESSION       : FALSE
   FILE_VOLUME_QUOTAS          : TRUE
   FILE_SUPPORTS_SPARSE_FILES  : FALSE
   FILE_SUPPORTS_REPARSE_POINTS: TRUE
   FILE_SUPPORTS_REMOTE_STORAGE: FALSE
   FILE_VOLUME_IS_COMPRESSED   : FALSE
   FILE_SUPPORTS_OBJECT_IDS    : FALSE
   FILE_SUPPORTS_ENCRYPTION    : FALSE
   FILE_NAMED_STREAMS          : FALSE
   FILE_READ_ONLY_VOLUME       : FALSE
   FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
   FILE_SUPPORTS_TRANSACTIONS  : FALSE

fsirl@FRAPC4 ~
$ df /cygdrive/t /cygdrive/l
Filesystem      1K-blocks       Used  Available Use% Mounted on
T:             5147067816 1790728936 3356338880  35% /cygdrive/t
L:              103303536   86715812   16587724  84% /cygdrive/l

fsirl@FRAPC4 ~
$ ls /cygdrive/t/ /cygdrive/l/
ls: cannot access '/cygdrive/t/': Not a directory
/cygdrive/l/:
automail  automail-lowpriority  drive_l.mrk  forward  intranet mailing  
officeuploads  rep  support  temp  www  wwwdir  wwwlogs wwwuploads

What can I do to track this down?

regards,
Franz Sirl

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

Re: Size limitation for NcFsd drive?

[Franz Sirl]

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/.


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

Re: Size limitation for NcFsd drive?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

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.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Size limitation for NcFsd drive?

[Franz Sirl]

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

Re: Size limitation for NcFsd drive?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 5099 bytes --]

Hi Franz,

On Jul 29 15:25, Franz Sirl wrote:
> Am 2016-07-28 um 21:58 schrieb Corinna Vinschen:
> > 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 "."

No, not at all.  It was timply never intended that symlink_info::check's
NtQueryDirectoryFile branch is called for top-level dirs.  The path split
works under the assumption that we're in some subdir.

> this drive it is just some file that happens to be first in the directory
> enumeration. And then everything goes wrong from there.

Your below strace indicates it's going pear-shaped a bit earlier:

> 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:\)

that's the debug_printf on line 2674.  NtCreateFile succeeds.

>   316  765465 [main] ls 7456 symlink_info::check: 0xC7E90006 =
> NtQueryInformationFile (\??\T:\)

This is the debug_printf on line 2766.  The status code returned at
this point is from conv_hdl.get_finfo() which in turn calls
file_get_fai(), defined in path.cc at line 1299ff.

I never saw this status code 0xC7E90006 before, but it comes very
likely from the device driver itself.  What that means is that
NtQueryInformationFile (..., FileAllInformation) has gone awry for
some reason.

This is a bit of a bummer.  FileAllInformation should work on all
supported filesystems.

> So upath was likely "\??\T:\" and I guess RtlSplitUnicodePath() returned
> "" or "*.*" for basename.

Don't guess, debug it!  Either install the cygwin-debuginfo package,
or build your own Cygwin without optimization for easier debugging.

> Maybe a possible fix/workaround would be to force basename to "." in this
> case?

In the first place it would be prudent to find out why the
FileAllInformation info class fails on this drive.  And in the second
place it would be important to find out how to fix this.  Potential
checks:

- Buffer alignment of the FILE_ALL_INFORMATION member in class
  path_conv_handle.

- Buffer size of the FILE_ALL_INFORMATION member.  For instance,
  does it work if the buffer is 1 byte bigger?  Or perhaps if
  the buffer is NAME_MAX bigger?

- If the above fails, adding a code path to file_get_fai for broken
  filesystems which calls NtQueryInformationFile twice, once with
  FileBasicInformation, once with FileStandardInformation info class.

  The old version of the function, called file_get_fnoi, had some
  code along these lines already.  For reference see

    git show eed35efb

> 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.

Yes, that may be the case.  We might have to revert code along the
lines of the old file_get_fnoi function to make it work again.
The desired result is that we *don't* call the NtQueryDirectoryFile
code path.  This is meant to be used only for files and dirs with no
permission to read their meta data.


HTH,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Size limitation for NcFsd drive?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

On Jul 29 16:18, Corinna Vinschen wrote:
> [...]
> - If the above fails, adding a code path to file_get_fai for broken
>   filesystems which calls NtQueryInformationFile twice, once with
>   FileBasicInformation, once with FileStandardInformation info class.
> 
>   The old version of the function, called file_get_fnoi, had some
>   code along these lines already.  For reference see
> 
>     git show eed35efb

Using gitweb that would be:

  https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=eed35efb


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Size limitation for NcFsd drive?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

On Jul 29 16:18, Corinna Vinschen wrote:
> In the first place it would be prudent to find out why the
> FileAllInformation info class fails on this drive.  And in the second
> place it would be important to find out how to fix this.  Potential
> checks:
> 
> - Buffer alignment of the FILE_ALL_INFORMATION member in class
>   path_conv_handle.
> 
> - Buffer size of the FILE_ALL_INFORMATION member.  For instance,
>   does it work if the buffer is 1 byte bigger?  Or perhaps if
>   the buffer is NAME_MAX bigger?

- There's also a chance (albeit minor) that the FileAllInformation call
  actually worked and the weird status code is just wrong.  After all,
  returning from this call with STATUS_BUFFER_OVERFLOW is valid, too,
  so I'd check for this as well here.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Size limitation for NcFsd drive?

[Franz Sirl]

Am 2016-07-29 um 16:38 schrieb Corinna Vinschen:
> On Jul 29 16:18, Corinna Vinschen wrote:
>> In the first place it would be prudent to find out why the
>> FileAllInformation info class fails on this drive.  And in the second
>> place it would be important to find out how to fix this.  Potential
>> checks:
>>
>> - Buffer alignment of the FILE_ALL_INFORMATION member in class
>>   path_conv_handle.
>>
>> - Buffer size of the FILE_ALL_INFORMATION member.  For instance,
>>   does it work if the buffer is 1 byte bigger?  Or perhaps if
>>   the buffer is NAME_MAX bigger?
>
> - There's also a chance (albeit minor) that the FileAllInformation call
>   actually worked and the weird status code is just wrong.  After all,
>   returning from this call with STATUS_BUFFER_OVERFLOW is valid, too,
>   so I'd check for this as well here.

Hi Corinna,

no, the error code isn't influenced by alignment or size. For local 
drives and SMB shares the STATUS_BUFFER_OVERFLOW turns into 
STATUS_SUCCESS as soon as there is enough room for the share path in the 
FILE_NAME_INFORMATION.FileName flexible array member (actually, why 
isn't path_conv_handle.attribs._fai larger? performance? 
FileNameInformation usually not needed?). But for the NCP share the 
strange error code for FileAllInformation remains. Checking all the 
members of FileAllInformation one by one, it turned out that it's the 
FileInternalIformation member that fails. I've reported it as a bug to 
Novell.

Nevertheless I believe the fallback to 
NtQueryDirectoryFile(FileIdBothDirectoryInformation) does not do what 
you want if the path is the root directory of a share. But that's not 
the cause of this problem.

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

Re: Size limitation for NcFsd drive?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3942 bytes --]

Hi Franz,

On Aug  2 16:26, Franz Sirl wrote:
> Am 2016-07-29 um 16:38 schrieb Corinna Vinschen:
> > On Jul 29 16:18, Corinna Vinschen wrote:
> > > In the first place it would be prudent to find out why the
> > > FileAllInformation info class fails on this drive.  And in the second
> > > place it would be important to find out how to fix this.  Potential
> > > checks:
> > > 
> > > - Buffer alignment of the FILE_ALL_INFORMATION member in class
> > >   path_conv_handle.
> > > 
> > > - Buffer size of the FILE_ALL_INFORMATION member.  For instance,
> > >   does it work if the buffer is 1 byte bigger?  Or perhaps if
> > >   the buffer is NAME_MAX bigger?
> > 
> > - There's also a chance (albeit minor) that the FileAllInformation call
> >   actually worked and the weird status code is just wrong.  After all,
> >   returning from this call with STATUS_BUFFER_OVERFLOW is valid, too,
> >   so I'd check for this as well here.
> 
> Hi Corinna,
> 
> no, the error code isn't influenced by alignment or size. For local drives
> and SMB shares the STATUS_BUFFER_OVERFLOW turns into STATUS_SUCCESS as soon
> as there is enough room for the share path in the
> FILE_NAME_INFORMATION.FileName flexible array member (actually, why isn't
> path_conv_handle.attribs._fai larger? performance? FileNameInformation
> usually not needed?).

FileNameInformation is the full path to the file.  It's not only not
needed, but for full long pathname support the buffer would have to
be sizeof (FILE_ALL_INFORMATION) + 32767 * sizeof (WCHAR), thus more
than 64K in size.

FileAllInformation is designed so that you can ask for all information
except the filename by just ignoring the name buffer requirements.  In
that case NtQueryInformationFile returns STATUS_BUFFER_OVERFLOW, which
can be ignored.

> But for the NCP share the strange error code for
> FileAllInformation remains. Checking all the members of FileAllInformation
> one by one, it turned out that it's the FileInternalIformation member that
> fails. I've reported it as a bug to Novell.

Cool.  NtQueryInformationFile is supposed to just set all unsupported
members to 0, see the Remarks section of
https://msdn.microsoft.com/en-us/library/windows/hardware/ff567052(v=vs.85).aspx

However, do we need a workaround?  Kind of like this:

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 970a0fe..d9ed357 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -1307,6 +1307,19 @@ file_get_fai (HANDLE h, PFILE_ALL_INFORMATION pfai)
 				   FileAllInformation);
   if (status == STATUS_BUFFER_OVERFLOW)
     status = STATUS_SUCCESS;
+  /* Filesystems with broken FileAllInformation exist, too.  See the thread
+     starting with https://cygwin.com/ml/cygwin/2016-07/msg00350.html. */
+  else if (!NT_SUCCESS (status) && status != STATUS_ACCESS_DENIED)
+    {
+      memset (pfai, 0, sizeof *pfai);
+      status = NtQueryInformationFile (h, &io, &pfai->BasicInformation,
+				       sizeof pfai->BasicInformation,
+				       FileBasicInformation);
+      if (NT_SUCCESS (status))
+	status = NtQueryInformationFile (h, &io, &pfai->StandardInformation,
+					 sizeof pfai->StandardInformation,
+					 FileStandardInformation);
+    }
   return status;
 }
 

> Nevertheless I believe the fallback to
> NtQueryDirectoryFile(FileIdBothDirectoryInformation) does not do what you
> want if the path is the root directory of a share. But that's not the cause
> of this problem.

Yeah, as I wrote in my reply, the NtQueryDirectoryFile branch isn't
supposed to be hit in this scenario.  It's solely for "access denied"
situations.

Are you set up to build your own Cygwin DLL so you can test the above
patch locally?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Size limitation for NcFsd drive?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4368 bytes --]

Franz?  Ping?


Thx,
Corinna

On Aug  2 16:59, Corinna Vinschen wrote:
> Hi Franz,
> 
> On Aug  2 16:26, Franz Sirl wrote:
> > Am 2016-07-29 um 16:38 schrieb Corinna Vinschen:
> > > On Jul 29 16:18, Corinna Vinschen wrote:
> > > > In the first place it would be prudent to find out why the
> > > > FileAllInformation info class fails on this drive.  And in the second
> > > > place it would be important to find out how to fix this.  Potential
> > > > checks:
> > > > 
> > > > - Buffer alignment of the FILE_ALL_INFORMATION member in class
> > > >   path_conv_handle.
> > > > 
> > > > - Buffer size of the FILE_ALL_INFORMATION member.  For instance,
> > > >   does it work if the buffer is 1 byte bigger?  Or perhaps if
> > > >   the buffer is NAME_MAX bigger?
> > > 
> > > - There's also a chance (albeit minor) that the FileAllInformation call
> > >   actually worked and the weird status code is just wrong.  After all,
> > >   returning from this call with STATUS_BUFFER_OVERFLOW is valid, too,
> > >   so I'd check for this as well here.
> > 
> > Hi Corinna,
> > 
> > no, the error code isn't influenced by alignment or size. For local drives
> > and SMB shares the STATUS_BUFFER_OVERFLOW turns into STATUS_SUCCESS as soon
> > as there is enough room for the share path in the
> > FILE_NAME_INFORMATION.FileName flexible array member (actually, why isn't
> > path_conv_handle.attribs._fai larger? performance? FileNameInformation
> > usually not needed?).
> 
> FileNameInformation is the full path to the file.  It's not only not
> needed, but for full long pathname support the buffer would have to
> be sizeof (FILE_ALL_INFORMATION) + 32767 * sizeof (WCHAR), thus more
> than 64K in size.
> 
> FileAllInformation is designed so that you can ask for all information
> except the filename by just ignoring the name buffer requirements.  In
> that case NtQueryInformationFile returns STATUS_BUFFER_OVERFLOW, which
> can be ignored.
> 
> > But for the NCP share the strange error code for
> > FileAllInformation remains. Checking all the members of FileAllInformation
> > one by one, it turned out that it's the FileInternalIformation member that
> > fails. I've reported it as a bug to Novell.
> 
> Cool.  NtQueryInformationFile is supposed to just set all unsupported
> members to 0, see the Remarks section of
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff567052(v=vs.85).aspx
> 
> However, do we need a workaround?  Kind of like this:
> 
> diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
> index 970a0fe..d9ed357 100644
> --- a/winsup/cygwin/path.cc
> +++ b/winsup/cygwin/path.cc
> @@ -1307,6 +1307,19 @@ file_get_fai (HANDLE h, PFILE_ALL_INFORMATION pfai)
>  				   FileAllInformation);
>    if (status == STATUS_BUFFER_OVERFLOW)
>      status = STATUS_SUCCESS;
> +  /* Filesystems with broken FileAllInformation exist, too.  See the thread
> +     starting with https://cygwin.com/ml/cygwin/2016-07/msg00350.html. */
> +  else if (!NT_SUCCESS (status) && status != STATUS_ACCESS_DENIED)
> +    {
> +      memset (pfai, 0, sizeof *pfai);
> +      status = NtQueryInformationFile (h, &io, &pfai->BasicInformation,
> +				       sizeof pfai->BasicInformation,
> +				       FileBasicInformation);
> +      if (NT_SUCCESS (status))
> +	status = NtQueryInformationFile (h, &io, &pfai->StandardInformation,
> +					 sizeof pfai->StandardInformation,
> +					 FileStandardInformation);
> +    }
>    return status;
>  }
>  
> 
> > Nevertheless I believe the fallback to
> > NtQueryDirectoryFile(FileIdBothDirectoryInformation) does not do what you
> > want if the path is the root directory of a share. But that's not the cause
> > of this problem.
> 
> Yeah, as I wrote in my reply, the NtQueryDirectoryFile branch isn't
> supposed to be hit in this scenario.  It's solely for "access denied"
> situations.
> 
> Are you set up to build your own Cygwin DLL so you can test the above
> patch locally?
> 
> 
> Thanks,
> Corinna
> 
> -- 
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat



-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Size limitation for NcFsd drive?

[Franz Sirl]

Sorry for the delay, for some reason my users keep me busy with strange 
bugs, see my answers below.

Am 2016-08-02 um 16:59 schrieb Corinna Vinschen:
> Hi Franz,
>
> On Aug  2 16:26, Franz Sirl wrote:
>> Nevertheless I believe the fallback to
>> NtQueryDirectoryFile(FileIdBothDirectoryInformation) does not do what you
>> want if the path is the root directory of a share. But that's not the cause
>> of this problem.
>
> Yeah, as I wrote in my reply, the NtQueryDirectoryFile branch isn't
> supposed to be hit in this scenario.  It's solely for "access denied"
> situations.

Got it.

> Are you set up to build your own Cygwin DLL so you can test the above
> patch locally?

Not really, but since I've already created a few testcases for Novell 
now, I have my own little "framework" using ntdll.dll directly. I added 
your code to it and it showed:

C:\NovellQueryAllInformationFile\Debug>NovellQueryAllInformationFile.exe t:\
NtQueryInformationFile(FileAllInformation) 't:\' resulted in errorcode 
c7e90006, description: (no description)
Returned filename:  ''
NtQueryInformationFile(FileBasicInformation) 't:\' resulted in errorcode 
0, description: STATUS_WAIT_0
NtQueryInformationFile(FileStandardInformation) 't:\' resulted in 
errorcode 0, description: STATUS_WAIT_0

So your fallback will work nicely. No idea if it's worth it, because 
I'll likely get an updated NCP client soon from Novell.

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

Re: Size limitation for NcFsd drive?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]

On Aug  4 20:31, Franz Sirl wrote:
> Sorry for the delay, for some reason my users keep me busy with strange
> bugs, see my answers below.

I know what you mean :)

> Am 2016-08-02 um 16:59 schrieb Corinna Vinschen:
> > Hi Franz,
> > 
> > On Aug  2 16:26, Franz Sirl wrote:
> > > Nevertheless I believe the fallback to
> > > NtQueryDirectoryFile(FileIdBothDirectoryInformation) does not do what you
> > > want if the path is the root directory of a share. But that's not the cause
> > > of this problem.
> > 
> > Yeah, as I wrote in my reply, the NtQueryDirectoryFile branch isn't
> > supposed to be hit in this scenario.  It's solely for "access denied"
> > situations.
> 
> Got it.
> 
> > Are you set up to build your own Cygwin DLL so you can test the above
> > patch locally?
> 
> Not really, but since I've already created a few testcases for Novell now, I
> have my own little "framework" using ntdll.dll directly. I added your code
> to it and it showed:
> 
> C:\NovellQueryAllInformationFile\Debug>NovellQueryAllInformationFile.exe t:\
> NtQueryInformationFile(FileAllInformation) 't:\' resulted in errorcode
> c7e90006, description: (no description)
> Returned filename:  ''
> NtQueryInformationFile(FileBasicInformation) 't:\' resulted in errorcode 0,
> description: STATUS_WAIT_0
> NtQueryInformationFile(FileStandardInformation) 't:\' resulted in errorcode
> 0, description: STATUS_WAIT_0
> 
> So your fallback will work nicely. No idea if it's worth it, because I'll
> likely get an updated NCP client soon from Novell.

Ok, thank you.  I applied a patch nevertheless, because we can never be
really sure there won't be another filesystems with the same problem.

I uploaded a new developer snapshot to https://cygwin.com/snapshots/
which contains my fix.  It would be nice if you could give it a try.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Size limitation for NcFsd drive?

[Franz Sirl]

Am 2016-08-05 um 11:30 schrieb Corinna Vinschen:
> On Aug  4 20:31, Franz Sirl wrote:
>> Sorry for the delay, for some reason my users keep me busy with strange
>> bugs, see my answers below.
>
> I know what you mean :)
>
>> Am 2016-08-02 um 16:59 schrieb Corinna Vinschen:
>>> Hi Franz,
>>>
>>> On Aug  2 16:26, Franz Sirl wrote:
>>>> Nevertheless I believe the fallback to
>>>> NtQueryDirectoryFile(FileIdBothDirectoryInformation) does not do what you
>>>> want if the path is the root directory of a share. But that's not the cause
>>>> of this problem.
>>>
>>> Yeah, as I wrote in my reply, the NtQueryDirectoryFile branch isn't
>>> supposed to be hit in this scenario.  It's solely for "access denied"
>>> situations.
>>
>> Got it.
>>
>>> Are you set up to build your own Cygwin DLL so you can test the above
>>> patch locally?
>>
>> Not really, but since I've already created a few testcases for Novell now, I
>> have my own little "framework" using ntdll.dll directly. I added your code
>> to it and it showed:
>>
>> C:\NovellQueryAllInformationFile\Debug>NovellQueryAllInformationFile.exe t:\
>> NtQueryInformationFile(FileAllInformation) 't:\' resulted in errorcode
>> c7e90006, description: (no description)
>> Returned filename:  ''
>> NtQueryInformationFile(FileBasicInformation) 't:\' resulted in errorcode 0,
>> description: STATUS_WAIT_0
>> NtQueryInformationFile(FileStandardInformation) 't:\' resulted in errorcode
>> 0, description: STATUS_WAIT_0
>>
>> So your fallback will work nicely. No idea if it's worth it, because I'll
>> likely get an updated NCP client soon from Novell.
>
> Ok, thank you.  I applied a patch nevertheless, because we can never be
> really sure there won't be another filesystems with the same problem.
>
> I uploaded a new developer snapshot to https://cygwin.com/snapshots/
> which contains my fix.  It would be nice if you could give it a try.

Hi Corinna,

the snapshot fixes the problem nicely, thanks!

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

Re: Size limitation for NcFsd drive?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

On Aug  5 16:57, Franz Sirl wrote:
> Am 2016-08-05 um 11:30 schrieb Corinna Vinschen:
> > On Aug  4 20:31, Franz Sirl wrote:
> > > [...]
> > > C:\NovellQueryAllInformationFile\Debug>NovellQueryAllInformationFile.exe t:\
> > > NtQueryInformationFile(FileAllInformation) 't:\' resulted in errorcode
> > > c7e90006, description: (no description)
> > > Returned filename:  ''
> > > NtQueryInformationFile(FileBasicInformation) 't:\' resulted in errorcode 0,
> > > description: STATUS_WAIT_0
> > > NtQueryInformationFile(FileStandardInformation) 't:\' resulted in errorcode
> > > 0, description: STATUS_WAIT_0
> > > 
> > > So your fallback will work nicely. No idea if it's worth it, because I'll
> > > likely get an updated NCP client soon from Novell.
> > 
> > Ok, thank you.  I applied a patch nevertheless, because we can never be
> > really sure there won't be another filesystems with the same problem.
> > 
> > I uploaded a new developer snapshot to https://cygwin.com/snapshots/
> > which contains my fix.  It would be nice if you could give it a try.
> 
> Hi Corinna,
> 
> the snapshot fixes the problem nicely, thanks!

Thanks a lot for testing!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]