Why does df fail to stat CIFS shares?

Why does df fail to stat CIFS shares?

[Alexander Schwab]

Hi everyone,

I have mounted some NetApp CIFS shares and I've now realized that df does
not return filesystem statistics for these shares. It looks like I can't figure
out why that is. Can anyone explain this behavior to me? 

I'm using cygwin 1.7.30(0.272/5/3). 

$ df
df: `/home/admaschwab'
df: `/home/aschwab'
df: `/cygdrive/u'
df: `/cygdrive/x'
df: `/cygdrive/y'
Filesystem     1K-blocks     Used Available Use% Mounted on
C:/cygwin/bin  186040316 72753352 113286964  40% /usr/bin
C:/cygwin/lib  186040316 72753352 113286964  40% /usr/lib
C:/cygwin      186040316 72753352 113286964  40% /
C:             186040316 72753352 113286964  40% /cygdrive/c

$ mount
//filer/user/admaschwab on /home/admaschwab type netapp (binary,notexec,user)
//filer/user/aschwab on /home/aschwab type netapp (binary,notexec,user)
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
U: on /cygdrive/u type netapp (binary,posix=0,user,noumount,auto)
X: on /cygdrive/x type netapp (binary,posix=0,user,noumount,auto)
Y: on /cygdrive/y type netapp (binary,posix=0,user,noumount,auto)

Thanks in advance.

Best regards,

Alex

--
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: Why does df fail to stat CIFS shares?

[Corinna Vinschen]

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

On Jun 27 16:36, Alexander Schwab wrote:
> Hi everyone,
> 
> I have mounted some NetApp CIFS shares and I've now realized that df does
> not return filesystem statistics for these shares. It looks like I can't figure
> out why that is. Can anyone explain this behavior to me? 
> 
> I'm using cygwin 1.7.30(0.272/5/3). 
> 
> $ df
> df: `/home/admaschwab'
> df: `/home/aschwab'
> df: `/cygdrive/u'
> df: `/cygdrive/x'
> df: `/cygdrive/y'

That's the real output?  No error message, just the names of the
mount points?  Is that the 32 or 64 bit Cygwin?

Given the lack of access to netapp drives, if this is a bug in Cygwin
(which seems likely in this case) I would need your cooperation to run
debugging sessions to be able to come up with a fix.  Is that ok?

For a start, could you run `strace -o df.strace df' and attach the
df.strace file to your reply?


Thanks,
Corinna

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

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

Re: Why does df fail to stat CIFS shares?

[Alexander Schwab]

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

> That's the real output?  No error message, just the names of the
> mount points?  Is that the 32 or 64 bit Cygwin?
> 
> Given the lack of access to netapp drives, if this is a bug in Cygwin
> (which seems likely in this case) I would need your cooperation to run
> debugging sessions to be able to come up with a fix.  Is that ok?
> 
> For a start, could you run `strace -o df.strace df' and attach the
> df.strace file to your reply?

Sorry, I forgot to answer the rest of your questions in the hurry:

arch: 
i686
uname -a:
CYGWIN_NT-6.1-WOW64 F1S712WWS 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 Cygwin
$ ldd `which df`
        ntdll.dll => /cygdrive/c/windows/SysWOW64/ntdll.dll (0x76ea0000)
        kernel32.dll => /cygdrive/c/windows/syswow64/kernel32.dll (0x74e40000)
        KERNELBASE.dll => /cygdrive/c/windows/syswow64/KERNELBASE.dll (0x75730000)
        SYSFER.DLL => /cygdrive/c/windows/SysWOW64/SYSFER.DLL (0x74670000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
        cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x67b10000)
        cygintl-8.dll => /usr/bin/cygintl-8.dll (0x6f7c0000)

Debugging sessions would of course be okay on a test machine.

I'm not quite sure if I installed cygwin in 32bit or 64bit flavour but I am
actually upgrading packages with setup-x86.exe for some months now..


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

Re: Why does df fail to stat CIFS shares?

[Corinna Vinschen]

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

On Jul  3 12:11, Alexander Schwab wrote:
> > That's the real output?  No error message, just the names of the
> > mount points?  Is that the 32 or 64 bit Cygwin?
> > 
> > Given the lack of access to netapp drives, if this is a bug in Cygwin
> > (which seems likely in this case) I would need your cooperation to run
> > debugging sessions to be able to come up with a fix.  Is that ok?
> > 
> > For a start, could you run `strace -o df.strace df' and attach the
> > df.strace file to your reply?
> 
> Sorry, I forgot to answer the rest of your questions in the hurry:

I don't see any other mail from you except this one...

> arch: 
> i686
> [...]
> Debugging sessions would of course be okay on a test machine.

Oh, I wouldn't access your machines.  I would just ask you per PM to run
certain commands or test DLLs if required.


Corinna

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

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

Re: Why does df fail to stat CIFS shares?

[Alexander Schwab]

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

On Thu, Jul 03, 2014 at 12:25:05PM +0200, Corinna Vinschen wrote:
> I don't see any other mail from you except this one...

I've now tried some variations of mails, but none of them is making it through to the list... :( As soon as I attach strace output (inline or as attachment), the mails are stuck at sourceware.org.

Regards
Alex 

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

Re: Why does df fail to stat CIFS shares?

[Alexander Schwab]

[-- Attachment #1.1: Type: text/plain, Size: 718 bytes --]

On Thu, Jul 03, 2014 at 12:25:05PM +0200, Corinna Vinschen wrote:
> I don't see any other mail from you except this one...

Sixth try:

Yes, that's the output - with no other clues. Maybe I did something dumb by
mounting my CIFS home shares into /home and changing permissions so that I can
access both admaschwab (my Domain Admin share) from my ordinary user account
aschwab and vice versa. I've attached the strace, relevant parts of passwd,
fstab, mount and cacls printout of the shares.

> Oh, I wouldn't access your machines.  I would just ask you per PM to run
> certain commands or test DLLs if required.

That's okay of course. :)

I've now attached only one tar/gz archive... Maybe that works.

Regards
Alex


[-- Attachment #1.2: strace-dump.tgz --]
[-- Type: application/x-tar-gz, Size: 17801 bytes --]

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

Re: Why does df fail to stat CIFS shares?

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> That's the real output?  No error message, just the names of the
> mount points?  Is that the 32 or 64 bit Cygwin?

Yes:

> df /home/gratz
df: ‘/home/gratz’

> Given the lack of access to netapp drives, if this is a bug in Cygwin
> (which seems likely in this case) I would need your cooperation to run
> debugging sessions to be able to come up with a fix.  Is that ok?

Sorry, can't do that.

> For a start, could you run `strace -o df.strace df' and attach the
> df.strace file to your reply?

My home dir is on a NetApp.  This one's mounted with ACL, but the same
happens for volumes that are mounted noacl.

> /usr/lib/csih/getVolInfo /home/gratz
Device Type        : 7
Characteristics    : 10
Volume Name        : <CIFS.HOMEDIR>
Serial Number      : 0
Max Filenamelength : 255
Filesystemname     : <NTFS>
Flags              : 4004f
  FILE_CASE_SENSITIVE_SEARCH  : TRUE
  FILE_CASE_PRESERVED_NAMES   : TRUE
  FILE_UNICODE_ON_DISK        : TRUE
  FILE_PERSISTENT_ACLS        : TRUE
  FILE_FILE_COMPRESSION       : FALSE
  FILE_VOLUME_QUOTAS          : FALSE
  FILE_SUPPORTS_SPARSE_FILES  : TRUE
  FILE_SUPPORTS_REPARSE_POINTS: FALSE
  FILE_SUPPORTS_REMOTE_STORAGE: FALSE
  FILE_VOLUME_IS_COMPRESSED   : FALSE
  FILE_SUPPORTS_OBJECT_IDS    : FALSE
  FILE_SUPPORTS_ENCRYPTION    : FALSE
  FILE_NAMED_STREAMS          : TRUE
  FILE_READ_ONLY_VOLUME       : FALSE
  FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
  FILE_SUPPORTS_TRANSACTIONS  : FALSE

The interesting part of the trace is this:

   37 2532956 [main] df 15880 get_info_from_sd: ACL 0x41C0, uid 1124017, gid
1049089
   54 2533010 [main] df 15880 fhandler_base::fstat_helper: 0 = fstat
(\??\H:\GNU, 0x22AA00) st_size=0, st_mode=0x41C0,
st_ino=-891439913066804700st_atim=53FB5E84.243D9E50
st_ctim=53F5EE0B.37D76CE8 st_mtim=53F5EE0B.37D76CE8 st_birthtim=3FB9EC6D.0
   39 2533049 [main] df 15880 stat_worker: 0 = (\??\H:\GNU,0x22AA00)
 2857 2535906 [main] df 15880 normalize_posix_path: src /home/gratz
   57 2535963 [main] df 15880 normalize_posix_path: /home/gratz =
normalize_posix_path (/home/gratz)
   39 2536002 [main] df 15880 mount_info::conv_to_win32_path:
conv_to_win32_path (/home/gratz)
   33 2536035 [main] df 15880 set_flags: flags: binary (0x2)
   32 2536067 [main] df 15880 mount_info::conv_to_win32_path: src_path
/home/gratz, dst H:\GNU, flags 0x2, rc 0
 1289 2537356 [main] df 15880 symlink_info::check: 0x0 = NtCreateFile
(\??\H:\GNU)
 3159 2540515 [main] df 15880 symlink_info::check: not a symlink
 1814 2542329 [main] df 15880 symlink_info::check: 0 = symlink.check(H:\GNU,
0x229330) (0x2)
   59 2542388 [main] df 15880 path_conv::check: this->path(H:\GNU), has_acls(1)
   49 2542437 [main] df 15880 build_fh_pc: fh 0x180331B38, dev 000000C3
   28 2542465 [main] df 15880 statvfs: (/home/gratz, 0x22A5E0),
file_attributes 48
 1404 2543869 [main] df 15880 fhandler_disk_file::fstatvfs: 0xC000000D =
NtQueryVolumeInformationFile(\??\H:\GNU, FileFsFullSizeInformation)
 2918 2546787 [main] df 15880 fhandler_disk_file::fstatvfs: -1 =
fstatvfs(/home/gratz, 0x22A5E0)
   71 2546858 [main] df 15880 statvfs: -1 = statvfs(/home/gratz,0x22A5E0),
errno 0
 1201 2548059 [main] df 15880 fhandler_pty_slave::write: pty1,
write(0x22AB30, 2)
   60 2548119 [main] df 15880 fhandler_pty_slave::write: (656): pty
output_mutex (0x190): waiting -1 ms
   43 2548162 [main] df 15880 fhandler_pty_slave::write: (656): pty
output_mutex: acquired
   43 2548205 [main] df 15880 fhandler_pty_slave::write: (671): pty
output_mutex(0x190) released
   34 2548239 [main] df 15880 write: 2 = write(2, 0x22AB30, 2)
   66 2548305 [main] df 15880 fhandler_pty_slave::write: pty1,
write(0x18022ADE1, 1)
   37 2548342 [main] df 15880 fhandler_pty_slave::write: (656): pty
output_mutex (0x190): waiting -1 ms
   47 2548389 [main] df 15880 fhandler_pty_slave::write: (656): pty
output_mutex: acquired
   40 2548429 [main] df 15880 fhandler_pty_slave::write: (671): pty
output_mutex(0x190) released
   34 2548463 [main] df 15880 write: 1 = write(2, 0x18022ADE1, 1)
   62 2548525 [main] df 15880 fhandler_pty_slave::write: pty1,
write(0x18022ADD5, 1)
   38 2548563 [main] df 15880 fhandler_pty_slave::write: (656): pty
output_mutex (0x190): waiting -1 ms
   56 2548619 [main] df 15880 fhandler_pty_slave::write: (656): pty
output_mutex: acquired
   39 2548658 [main] df 15880 fhandler_pty_slave::write: (671): pty
output_mutex(0x190) released
   34 2548692 [main] df 15880 write: 1 = write(2, 0x18022ADD5, 1)
  307 2548999 [main] df 15880 fhandler_pty_slave::write: pty1,
write(0x10041C0C0, 17)
   40 2549039 [main] df 15880 fhandler_pty_slave::write: (656): pty
output_mutex (0x190): waiting -1 ms
   41 2549080 [main] df 15880 fhandler_pty_slave::write: (656): pty
output_mutex: acquired
   39 2549119 [main] df 15880 fhandler_pty_slave::write: (671): pty
output_mutex(0x190) released
   34 2549153 [main] df 15880 write: 17 = write(2, 0x10041C0C0, 17)
  577 2549730 [main] df 15880 fhandler_pty_slave::write: pty1,
write(0x1801D4907, 1)
   39 2549769 [main] df 15880 fhandler_pty_slave::write: (656): pty
output_mutex (0x190): waiting -1 ms
   42 2549811 [main] df 15880 fhandler_pty_slave::write: (656): pty
output_mutex: acquired
   39 2549850 [main] df 15880 fhandler_pty_slave::write: (671): pty
output_mutex(0x190) released
   34 2549884 [main] df 15880 write: 1 = write(2, 0x1801D4907, 1)
  581 2550465 [main] df 15880 close: close(1)
   38 2550503 [main] df 15880 fhandler_base::close: closing '' handle 0x228
   34 2550537 [main] df 15880 close: 0 = close(1)
  412 2550949 [main] df 15880 close: close(2)


Regards,
Achim.


--
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: Why does df fail to stat CIFS shares?

[Corinna Vinschen]

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

On Aug 26 09:14, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > (which seems likely in this case) I would need your cooperation to run
> > debugging sessions to be able to come up with a fix.  Is that ok?
> 
> Sorry, can't do that.

Then you have to build your own Cygwin DLL for testing.

>    28 2542465 [main] df 15880 statvfs: (/home/gratz, 0x22A5E0),
> file_attributes 48
>  1404 2543869 [main] df 15880 fhandler_disk_file::fstatvfs: 0xC000000D =
> NtQueryVolumeInformationFile(\??\H:\GNU, FileFsFullSizeInformation)

The call to NtQueryVolumeInformationFile() in
fhandler_disk_file::fstatvfs() in fhandler_disk_file.cc (line 737ff),
fails with STATUS_INVALID_PARAMETER.  This is a NetApp bug, but we may
be able to workaround it.

Given the lack of complex parameters, and given that, as you claim, this
occurs on 32 and 64 bit, I can see only one (well, two) potential
culprits, the NtOpenFile calls at lines 751 and 761.  One of the
following is the problem:

- The Netapp drive chokes on the FILE_OPEN_FOR_BACKUP_INTENT open flags.
  This is *very* unlikely, though, given that it's a required flag to
  open a directory.  Nevertheless, try to set it to 0 just for testing.

- Or, Netapp expects the call to run in SYNCHRONIZE mode.  To test that,
  set the open mode to READ_CONTROL|SYNCHRONIZE.  This also requires to
  set the open flags to
  FILE_OPEN_FOR_BACKUP_INTENT|FILE_SYNCHRONOUS_IO_NONALERT

- Or, the READ_CONTROL open mode isn't enough for Netapp.  Try to open
  the file with GENERIC_READ for a start, and then, if that works, try
  to reduce the flags to something containing READ_CONTROL,
  FILE_OPEN_DATA, and FILE_OPEN_ATTRIBUTES.  Try in combination with
  SYNCHRONIZE and FILE_SYNCHRONOUS_IO_NONALERT.


Corinna

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

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

Re: Why does df fail to stat CIFS shares?

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> Then you have to build your own Cygwin DLL for testing.

I've just set up for a build and ran into this (with the snapshot sources
from 2014-08-19 since these were the ones I had at hand):

ccwrap -g -O2 -O3 -mtune=core2 -march=core2 -Wall -Wstrict-aliasing
-Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD
-fomit-frame-pointer -Werror -fmerge-constants -ftracer -mcmodel=small -c -o
regcomp.o ../../.././winsup/cygwin/regex/regcomp.c
../../.././winsup/cygwin/regex/regcomp.c: In function ‘p_bracket’:
../../.././winsup/cygwin/regex/regcomp.c:1249:12: error: ‘s’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
  wint_t i, s, n;

So I configured again with --disable-werror, lets see if that produces a
usable DLL now.


Regards,
Achim.


--
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: Why does df fail to stat CIFS shares?

[Corinna Vinschen]

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

On Aug 26 15:00, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > Then you have to build your own Cygwin DLL for testing.
> 
> I've just set up for a build and ran into this (with the snapshot sources
> from 2014-08-19 since these were the ones I had at hand):
> 
> ccwrap -g -O2 -O3 -mtune=core2 -march=core2 -Wall -Wstrict-aliasing
            ^^^^^^^
	    Huh?

Did you specify -O3 explicitely?  Don't.  -O2 is default and sufficient.


Corinna

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

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

Re: Why does df fail to stat CIFS shares?

[Achim Gratz]

Corinna Vinschen writes:
>> I've just set up for a build and ran into this (with the snapshot sources
>> from 2014-08-19 since these were the ones I had at hand):
>> 
>> ccwrap -g -O2 -O3 -mtune=core2 -march=core2 -Wall -Wstrict-aliasing
>             ^^^^^^^
> 	    Huh?
>
> Did you specify -O3 explicitely?  Don't.  -O2 is default and sufficient.

I think it has picked up some settings from the environment.  I will
investigate tomorrow, I don't use this machine for builds normally.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
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: Why does df fail to stat CIFS shares?

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > I've just set up for a build and ran into this (with the snapshot sources
> > from 2014-08-19 since these were the ones I had at hand):

Sorted.  I just did a native build from the 2014-08-25 snapshot (which is
also the installed version).  Now what, is it enough to put the cygwin1.dll
and df into the same directory, set up the path to include it and run df? 
Just tried that and getting a Cygwin Base Heap mismatch... 


Regards,
Achim.


--
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: Why does df fail to stat CIFS shares?

[Corinna Vinschen]

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

On Aug 27 09:23, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > I've just set up for a build and ran into this (with the snapshot sources
> > > from 2014-08-19 since these were the ones I had at hand):
> 
> Sorted.  I just did a native build from the 2014-08-25 snapshot (which is
> also the installed version).

It's easier to do this from CVS.  It also allows to create diffs
most easily.  Did you build outside the source dir, as required?

> Now what, is it enough to put the cygwin1.dll
> and df into the same directory, set up the path to include it and run df? 
> Just tried that and getting a Cygwin Base Heap mismatch... 

Just copy your original cygwin1.dll somewhere else and replace
cygwin1.dll in /bin with your new_cygwin1.dll.  This is assuming
you're using a test machine exclusively.  Make sure the DLL is
executable.


Corinna

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

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

Re: Why does df fail to stat CIFS shares?

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> It's easier to do this from CVS.  It also allows to create diffs
> most easily.  Did you build outside the source dir, as required?

No can do CVS here... I just did a "./configure && make", which seemed to
work (it built into x86_64_unknown_cygwin).

> > Now what, is it enough to put the cygwin1.dll
> > and df into the same directory, set up the path to include it and run df? 
> > Just tried that and getting a Cygwin Base Heap mismatch... 
> 
> Just copy your original cygwin1.dll somewhere else and replace
> cygwin1.dll in /bin with your new_cygwin1.dll.  This is assuming
> you're using a test machine exclusively.  Make sure the DLL is
> executable.

OK, so it's more involved than I'd hoped, I'll have to set up a test
installation then.  Anyway, time has ran out for today.


Regards,
Achim.


--
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: Why does df fail to stat CIFS shares?

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> The call to NtQueryVolumeInformationFile() in
> fhandler_disk_file::fstatvfs() in fhandler_disk_file.cc (line 737ff),
> fails with STATUS_INVALID_PARAMETER.  This is a NetApp bug, but we may
> be able to workaround it.

The bug (if there is one) is that the driver should return
STATUS_INVALID_INFO_CLASS since it quite obviously doesn't support that info
class request.  Falling back to FileFsSizeINformation does and returns
sensible values for all NetApp volumes.  Since at least all NetApp volumes
here run without quotas anyway, no information loss occurs IIUC.


Regards,
Achim.



--
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: Why does df fail to stat CIFS shares?

[Corinna Vinschen]

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

On Aug 27 15:06, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > The call to NtQueryVolumeInformationFile() in
> > fhandler_disk_file::fstatvfs() in fhandler_disk_file.cc (line 737ff),
> > fails with STATUS_INVALID_PARAMETER.  This is a NetApp bug, but we may
> > be able to workaround it.
> 
> The bug (if there is one) is that the driver should return
> STATUS_INVALID_INFO_CLASS since it quite obviously doesn't support that info
> class request.  Falling back to FileFsSizeINformation does and returns
> sensible values for all NetApp volumes.  Since at least all NetApp volumes
> here run without quotas anyway, no information loss occurs IIUC.

-v, please.  What means "obviously" here?  Did you ask Netapp?

The FileFsFullSizeInformation class is *old*, it has been introduced
with Windows 2000.  Did you test all combinations I asked you for?  Can
you provide detailed results?  It might help to find a working combination.


Corinna

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

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

Re: Why does df fail to stat CIFS shares?

[Corinna Vinschen]

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

On Aug 27 17:15, Corinna Vinschen wrote:
> On Aug 27 15:06, Achim Gratz wrote:
> > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > The call to NtQueryVolumeInformationFile() in
> > > fhandler_disk_file::fstatvfs() in fhandler_disk_file.cc (line 737ff),
> > > fails with STATUS_INVALID_PARAMETER.  This is a NetApp bug, but we may
> > > be able to workaround it.
> > 
> > The bug (if there is one) is that the driver should return
> > STATUS_INVALID_INFO_CLASS since it quite obviously doesn't support that info
> > class request.  Falling back to FileFsSizeINformation does and returns
> > sensible values for all NetApp volumes.  Since at least all NetApp volumes
> > here run without quotas anyway, no information loss occurs IIUC.
> 
> -v, please.  What means "obviously" here?  Did you ask Netapp?
> 
> The FileFsFullSizeInformation class is *old*, it has been introduced
> with Windows 2000.  Did you test all combinations I asked you for?  Can
> you provide detailed results?  It might help to find a working combination.

Btw., one other hare-brained idea would be if the Netapp FS has a
somewhat different idea of the size of FILE_FS_FULL_SIZE_INFORMATION,
maybe due to a misunderstanding in alignment.  What you could try is
to make full_fsi a pointer:

  PFILE_FS_FULL_SIZE_INFORMATION full_fsi =
  	(PFILE_FS_FULL_SIZE_INFORMATION)
	alloca (2 * sizeof (FILE_FS_FULL_SIZE_INFORMATION));

and then change all "full_fsi." to "full_fsi->"

If nothing else works, try this workaround for size:

Index: fhandler_disk_file.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/fhandler_disk_file.cc,v
retrieving revision 1.401
diff -u -p -r1.401 fhandler_disk_file.cc
--- fhandler_disk_file.cc	27 Aug 2014 11:42:17 -0000	1.401
+++ fhandler_disk_file.cc	27 Aug 2014 15:36:44 -0000
@@ -800,6 +800,26 @@ fhandler_disk_file::fstatvfs (struct sta
 	}
       ret = 0;
     }
+  else if (status == STATUS_INVALID_PARAMETER /* Netapp */
+	   || status == STATUS_INVALID_INFO_CLASS)
+    {
+      FILE_FS_SIZE_INFORMATION fsi;
+      status = NtQueryVolumeInformationFile (fh, &io, &fsi, sizeof fsi,
+					     FileFsSizeInformation);
+      if (NT_SUCCESS (status))
+	{
+	  sfs->f_bsize = fsi.BytesPerSector * fsi.SectorsPerAllocationUnit;
+	  sfs->f_frsize = sfs->f_bsize;
+	  sfs->f_blocks = (fsblkcnt_t) fsi.TotalAllocationUnits.QuadPart;
+	  sfs->f_bfree = sfs->f_bavail =
+	    (fsblkcnt_t) fsi.AvailableAllocationUnits.QuadPart;
+	  ret = 0;
+	}
+      else
+	debug_printf ("%y = NtQueryVolumeInformationFile"
+		      "(%S, FileFsSizeInformation)", 
+		      status, pc.get_nt_native_path ());
+    }
   else
     debug_printf ("%y = NtQueryVolumeInformationFile"
 		  "(%S, FileFsFullSizeInformation)", 


Corinna

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

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

Re: Why does df fail to stat CIFS shares?

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > -v, please.  What means "obviously" here?  Did you ask Netapp?

No, I've tried all combinations of parameters to the open calls to
absolutely no avail.  I then started to look at what the VolumeInformation
call is supposed to be doing and decided that this might have a better
chance of producing a workaround.

> > The FileFsFullSizeInformation class is *old*, it has been introduced
> > with Windows 2000.  Did you test all combinations I asked you for?  Can
> > you provide detailed results?  It might help to find a working combination.

All combinations you listed produced absolutely the same behaviour than
before: the open suceeds and the VolumeInfo call fails.  I've tried a few
other combinations that are forbidden according to MSDN and promptly had the
open call fail, so I think I did this correctly...

While searching the net I've found some notes saying that the only classes
confirmed working everywhere didn't include FileFsFullSizeInformation.  True
or not, that's what pushed me to rip it out.

http://sourceforge.net/p/openxdk/patches/_discuss/thread/4b412944/4ba5/attachment/undocumented.txt

> Btw., one other hare-brained idea would be if the Netapp FS has a
> somewhat different idea of the size of FILE_FS_FULL_SIZE_INFORMATION,
> maybe due to a misunderstanding in alignment.  What you could try is
> to make full_fsi a pointer:
> 
>   PFILE_FS_FULL_SIZE_INFORMATION full_fsi =
>   	(PFILE_FS_FULL_SIZE_INFORMATION)
> 	alloca (2 * sizeof (FILE_FS_FULL_SIZE_INFORMATION));
> 
> and then change all "full_fsi." to "full_fsi->"

Tomorrow...

> If nothing else works, try this workaround for size:

That's essentially what I've done to get it working.  Not that exact patch,
so I'll try that out tomorrow as well, but that code path should produce
correct output from df no matter of what FS it finds behind the mount.


Regards,
Achim.




--
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: Why does df fail to stat CIFS shares?

[Corinna Vinschen]

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

On Aug 27 16:28, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > -v, please.  What means "obviously" here?  Did you ask Netapp?
> 
> No, I've tried all combinations of parameters to the open calls to
> absolutely no avail.  I then started to look at what the VolumeInformation
> call is supposed to be doing and decided that this might have a better
> chance of producing a workaround.
> 
> > > The FileFsFullSizeInformation class is *old*, it has been introduced
> > > with Windows 2000.  Did you test all combinations I asked you for?  Can
> > > you provide detailed results?  It might help to find a working combination.
> 
> All combinations you listed produced absolutely the same behaviour than
> before: the open suceeds and the VolumeInfo call fails.  I've tried a few
> other combinations that are forbidden according to MSDN and promptly had the
> open call fail, so I think I did this correctly...
> 
> While searching the net I've found some notes saying that the only classes
> confirmed working everywhere didn't include FileFsFullSizeInformation.  True
> or not, that's what pushed me to rip it out.
> 
> http://sourceforge.net/p/openxdk/patches/_discuss/thread/4b412944/4ba5/attachment/undocumented.txt
> 
> > Btw., one other hare-brained idea would be if the Netapp FS has a
> > somewhat different idea of the size of FILE_FS_FULL_SIZE_INFORMATION,
> > maybe due to a misunderstanding in alignment.  What you could try is
> > to make full_fsi a pointer:
> > 
> >   PFILE_FS_FULL_SIZE_INFORMATION full_fsi =
> >   	(PFILE_FS_FULL_SIZE_INFORMATION)
> > 	alloca (2 * sizeof (FILE_FS_FULL_SIZE_INFORMATION));
> > 
> > and then change all "full_fsi." to "full_fsi->"

Make that:

  PFILE_FS_FULL_SIZE_INFORMATION pfull_fsi =
        (PFILE_FS_FULL_SIZE_INFORMATION)
	alloca (2 * sizeof (FILE_FS_FULL_SIZE_INFORMATION));
  FILE_FS_FULL_SIZE_INFORMATION &full_fsi = *pfull_fsi;

Then you don't have to change subsequent code.

> Tomorrow...

Ok.


Corinna

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

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

Re: Why does df fail to stat CIFS shares?

[Corinna Vinschen]

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

On Aug 27 19:04, Corinna Vinschen wrote:
> On Aug 27 16:28, Achim Gratz wrote:
> > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > > -v, please.  What means "obviously" here?  Did you ask Netapp?
> > 
> > No, I've tried all combinations of parameters to the open calls to
> > absolutely no avail.  I then started to look at what the VolumeInformation
> > call is supposed to be doing and decided that this might have a better
> > chance of producing a workaround.
> > 
> > > > The FileFsFullSizeInformation class is *old*, it has been introduced
> > > > with Windows 2000.  Did you test all combinations I asked you for?  Can
> > > > you provide detailed results?  It might help to find a working combination.
> > 
> > All combinations you listed produced absolutely the same behaviour than
> > before: the open suceeds and the VolumeInfo call fails.  I've tried a few
> > other combinations that are forbidden according to MSDN and promptly had the
> > open call fail, so I think I did this correctly...
> > 
> > While searching the net I've found some notes saying that the only classes
> > confirmed working everywhere didn't include FileFsFullSizeInformation.  True
> > or not, that's what pushed me to rip it out.
> > 
> > http://sourceforge.net/p/openxdk/patches/_discuss/thread/4b412944/4ba5/attachment/undocumented.txt

Btw., the document is from 2003.  11 years is a long time.


Corinna

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

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

Re: Why does df fail to stat CIFS shares?

[Corinna Vinschen]

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

On Aug 27 16:28, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > -v, please.  What means "obviously" here?  Did you ask Netapp?
> 
> No, I've tried all combinations of parameters to the open calls to
> absolutely no avail.  I then started to look at what the VolumeInformation
> call is supposed to be doing and decided that this might have a better
> chance of producing a workaround.
> 
> > > The FileFsFullSizeInformation class is *old*, it has been introduced
> > > with Windows 2000.  Did you test all combinations I asked you for?  Can
> > > you provide detailed results?  It might help to find a working combination.
> 
> All combinations you listed produced absolutely the same behaviour than
> before: the open suceeds and the VolumeInfo call fails.  I've tried a few
> other combinations that are forbidden according to MSDN and promptly had the
> open call fail, so I think I did this correctly...
> 
> While searching the net I've found some notes saying that the only classes
> confirmed working everywhere didn't include FileFsFullSizeInformation.  True
> or not, that's what pushed me to rip it out.
> 
> http://sourceforge.net/p/openxdk/patches/_discuss/thread/4b412944/4ba5/attachment/undocumented.txt
> 
> > Btw., one other hare-brained idea would be if the Netapp FS has a
> > somewhat different idea of the size of FILE_FS_FULL_SIZE_INFORMATION,
> > maybe due to a misunderstanding in alignment.  What you could try is
> > to make full_fsi a pointer:
> > 
> >   PFILE_FS_FULL_SIZE_INFORMATION full_fsi =
> >   	(PFILE_FS_FULL_SIZE_INFORMATION)
> > 	alloca (2 * sizeof (FILE_FS_FULL_SIZE_INFORMATION));
> > 
> > and then change all "full_fsi." to "full_fsi->"
> 
> Tomorrow...
> 
> > If nothing else works, try this workaround for size:
> 
> That's essentially what I've done to get it working.  Not that exact patch,
> so I'll try that out tomorrow as well, but that code path should produce
> correct output from df no matter of what FS it finds behind the mount.

I've applied my patch since it certainly doesn't hurt.  At least not
more than those bugs in various filesystems.  It seems the minimal
requirements for filesystems to get MSFT blessing are *very* low :(


Corinna

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

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

Re: Why does df fail to stat CIFS shares?

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> >
[...]

The patch with the fallback to FileFsSizeInformation works as expected.

> > > Btw., one other hare-brained idea would be if the Netapp FS has a
> > > somewhat different idea of the size of FILE_FS_FULL_SIZE_INFORMATION,
> > > maybe due to a misunderstanding in alignment.  What you could try is
> > > to make full_fsi a pointer:

The FileFsFullSizeInformation path still fails with the same error code even
with these changes (I've added a few debug_printf to show the results even
in the case of success):

   31 3473313 [main] df 28752 statvfs: (/home/gratz, 0x28A864),
file_attributes 48
 1186 3474499 [main] df 28752 fhandler_disk_file::fstatvfs: 0xC000000D =
NtQueryVolumeInformationFile(\??\H:\GNU, FileFsFullSizeInformation)
  479 3474978 [main] df 28752 fhandler_disk_file::fstatvfs: 0x0 =
NtQueryVolumeInformationFile(\??\H:\GNU, FileFsSizeInformation)
 1709 3476687 [main] df 28752 fhandler_disk_file::fstatvfs: 0 =
fstatvfs(/home/gratz, 0x28A864)
   34 3476721 [main] df 28752 statvfs: 0 = statvfs(/home/gratz,0x28A864)


Regards,
Achim.


--
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: Why does df fail to stat CIFS shares?

[Corinna Vinschen]

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

On Aug 28 14:58, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > >
> [...]
> 
> The patch with the fallback to FileFsSizeInformation works as expected.
> 
> > > > Btw., one other hare-brained idea would be if the Netapp FS has a
> > > > somewhat different idea of the size of FILE_FS_FULL_SIZE_INFORMATION,
> > > > maybe due to a misunderstanding in alignment.  What you could try is
> > > > to make full_fsi a pointer:
> 
> The FileFsFullSizeInformation path still fails with the same error code even
> with these changes (I've added a few debug_printf to show the results even
> in the case of success):
> 
>    31 3473313 [main] df 28752 statvfs: (/home/gratz, 0x28A864),
> file_attributes 48
>  1186 3474499 [main] df 28752 fhandler_disk_file::fstatvfs: 0xC000000D =
> NtQueryVolumeInformationFile(\??\H:\GNU, FileFsFullSizeInformation)
>   479 3474978 [main] df 28752 fhandler_disk_file::fstatvfs: 0x0 =
> NtQueryVolumeInformationFile(\??\H:\GNU, FileFsSizeInformation)
>  1709 3476687 [main] df 28752 fhandler_disk_file::fstatvfs: 0 =
> fstatvfs(/home/gratz, 0x28A864)
>    34 3476721 [main] df 28752 statvfs: 0 = statvfs(/home/gratz,0x28A864)

#$%@ netapp #@$%


Corinna

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

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