* Size limitation for NcFsd drive?
@ 2016-07-28 10:35 Franz Sirl
2016-07-28 16:36 ` Franz Sirl
0 siblings, 1 reply; 14+ messages in thread
From: Franz Sirl @ 2016-07-28 10:35 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-07-28 10:35 Size limitation for NcFsd drive? Franz Sirl
@ 2016-07-28 16:36 ` Franz Sirl
2016-07-28 20:20 ` Corinna Vinschen
0 siblings, 1 reply; 14+ messages in thread
From: Franz Sirl @ 2016-07-28 16:36 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-07-28 16:36 ` Franz Sirl
@ 2016-07-28 20:20 ` Corinna Vinschen
2016-07-29 14:26 ` Franz Sirl
0 siblings, 1 reply; 14+ messages in thread
From: Corinna Vinschen @ 2016-07-28 20:20 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-07-28 20:20 ` Corinna Vinschen
@ 2016-07-29 14:26 ` Franz Sirl
2016-07-29 14:38 ` Corinna Vinschen
0 siblings, 1 reply; 14+ messages in thread
From: Franz Sirl @ 2016-07-29 14:26 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-07-29 14:26 ` Franz Sirl
@ 2016-07-29 14:38 ` Corinna Vinschen
2016-07-29 16:00 ` Corinna Vinschen
2016-07-29 19:32 ` Corinna Vinschen
0 siblings, 2 replies; 14+ messages in thread
From: Corinna Vinschen @ 2016-07-29 14:38 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-07-29 14:38 ` Corinna Vinschen
@ 2016-07-29 16:00 ` Corinna Vinschen
2016-07-29 19:32 ` Corinna Vinschen
1 sibling, 0 replies; 14+ messages in thread
From: Corinna Vinschen @ 2016-07-29 16:00 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-07-29 14:38 ` Corinna Vinschen
2016-07-29 16:00 ` Corinna Vinschen
@ 2016-07-29 19:32 ` Corinna Vinschen
2016-08-02 14:26 ` Franz Sirl
1 sibling, 1 reply; 14+ messages in thread
From: Corinna Vinschen @ 2016-07-29 19:32 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-07-29 19:32 ` Corinna Vinschen
@ 2016-08-02 14:26 ` Franz Sirl
2016-08-02 14:59 ` Corinna Vinschen
0 siblings, 1 reply; 14+ messages in thread
From: Franz Sirl @ 2016-08-02 14:26 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-08-02 14:26 ` Franz Sirl
@ 2016-08-02 14:59 ` Corinna Vinschen
2016-08-04 12:36 ` Corinna Vinschen
2016-08-04 23:01 ` Franz Sirl
0 siblings, 2 replies; 14+ messages in thread
From: Corinna Vinschen @ 2016-08-02 14:59 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-08-02 14:59 ` Corinna Vinschen
@ 2016-08-04 12:36 ` Corinna Vinschen
2016-08-04 23:01 ` Franz Sirl
1 sibling, 0 replies; 14+ messages in thread
From: Corinna Vinschen @ 2016-08-04 12:36 UTC (permalink / raw)
To: cygwin; +Cc: Franz Sirl
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-08-02 14:59 ` Corinna Vinschen
2016-08-04 12:36 ` Corinna Vinschen
@ 2016-08-04 23:01 ` Franz Sirl
2016-08-05 10:53 ` Corinna Vinschen
1 sibling, 1 reply; 14+ messages in thread
From: Franz Sirl @ 2016-08-04 23:01 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-08-04 23:01 ` Franz Sirl
@ 2016-08-05 10:53 ` Corinna Vinschen
2016-08-05 15:15 ` Franz Sirl
0 siblings, 1 reply; 14+ messages in thread
From: Corinna Vinschen @ 2016-08-05 10:53 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-08-05 10:53 ` Corinna Vinschen
@ 2016-08-05 15:15 ` Franz Sirl
2016-08-05 15:21 ` Corinna Vinschen
0 siblings, 1 reply; 14+ messages in thread
From: Franz Sirl @ 2016-08-05 15:15 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Size limitation for NcFsd drive?
2016-08-05 15:15 ` Franz Sirl
@ 2016-08-05 15:21 ` Corinna Vinschen
0 siblings, 0 replies; 14+ messages in thread
From: Corinna Vinschen @ 2016-08-05 15:21 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-08-05 15:05 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-28 10:35 Size limitation for NcFsd drive? Franz Sirl
2016-07-28 16:36 ` Franz Sirl
2016-07-28 20:20 ` Corinna Vinschen
2016-07-29 14:26 ` Franz Sirl
2016-07-29 14:38 ` Corinna Vinschen
2016-07-29 16:00 ` Corinna Vinschen
2016-07-29 19:32 ` Corinna Vinschen
2016-08-02 14:26 ` Franz Sirl
2016-08-02 14:59 ` Corinna Vinschen
2016-08-04 12:36 ` Corinna Vinschen
2016-08-04 23:01 ` Franz Sirl
2016-08-05 10:53 ` Corinna Vinschen
2016-08-05 15:15 ` Franz Sirl
2016-08-05 15:21 ` Corinna Vinschen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).