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


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

opendir/readdir failure on non-Samba Unix-hosted remote volumess


For some time now, on and off, I've been looking at a problem that arose
somewhere between the release of Cygwin.dll-1.5.18-2 and 1.5.19-4.  I'm
not actually a Cygwin user myself, but I support several such.

Our main fileserver is Solaris running TotalNet Advanced Server (TAS),
which is `Samba-like, but not Samba' from the Windows PoV at least.  In
the time since the problem first arose, this hardware, the Solaris version
it runs, and the TAS version on top of that, have changed without changing
the nature of the problem at the Cygwin client end.

All cygwin.dll releases since 1.5.18-1 produce 100% failure for any
operation which (apparently) involves opendir/readdir operations, the most
obvious of which is `ls'.  Any attempt since 1.5.18-1 to run `ls' against
any directory mounted from our TAS server results in

  ls: reading directory DIR: [ERROR]

where `DIR' is the directory name mentioned and `[ERROR]' is some
errno.h-like message, which was `Permission denied' under 1.5.19-4, but
has become `Function not implemented' at some point since then.

Following this via sources as far as possible, I note that the only way to
get the above error message from `ls' is if the readdir() fails, and it
seems that there are a fairly limited number of ways to get ENOSYS from
fhandler_disk_file.cc.

Without having the means (as far as I know) to draw out exactly what's
happening, it seems to me that since 1.5.18-1, special arrangements have
been made to handle directories on Samba-originated volumes that may have
frustrated successful operation of Cygwin against similar Unix-originated
volumes.  For some time, we've worked on the theory that Cygwin is working
properly and our TAS server is at fault, but having gone back to the code,
I'm not so sure any more.  My current feeling is that opendir() isn't
conditioning the file-handler satisfactorily for subsequent readdir() on
our remote volume, but I'm unsure exactly how.

This particular problem is referred to directly in

  http://www.cygwin.com/ml/cygwin/2006-11/msg00568.html
  http://www.cygwin.com/ml/cygwin/2008-07/msg00534.html

and it looks as if a very similar problem is seen by someone else in

  http://www.nabble.com/How-to-correctly-setup-passwd-and-group-to-access-mounted-drives--td17669276.html

For a long time, we've been looking at it as a
Windows/AD/domain-permissions-related problem, working on the theory that
our Solaris server isn't quite behaving properly with respect to
permissions, but when I look at the amount of work done on the
opendir/readdir code between July 2005 and early 2006, especially given
that some of it was Samba-related, I'm now wondering if it isn't a Cygwin
coding issue.

When I run `strace ls' (the TAS-mounted filesystem is H:\ in this case) I
get the following (excerpt):

----------------------------------------------------------------
  578  129008 [main] ls 1624 normalize_posix_path: src .
  302  129310 [main] ls 1624 cwdstuff::get: posix /cygdrive/h
  369  129679 [main] ls 1624 cwdstuff::get: (/cygdrive/h) = cwdstuff::get
(0x22C850, 260, 1, 0), errno 0
  378  130057 [main] ls 1624 normalize_posix_path: /cygdrive/h/ =
normalize_posix_path (.)
  387  130444 [main] ls 1624 mount_info::conv_to_win32_path:
conv_to_win32_path (/cygdrive/h)
  364  130808 [main] ls 1624 mount_info::cygdrive_win32_path: src
'/cygdrive/h', dst 'h:\'
  397  131205 [main] ls 1624 set_flags: flags: binary (0x2)
  349  131554 [main] ls 1624 mount_info::conv_to_win32_path: src_path
/cygdrive/h, dst h:\, flags 0x2A, rc 0
 6556  138110 [main] ls 1624 symlink_info::check: not a symlink
  377  138487 [main] ls 1624 symlink_info::check: 0 = symlink.check (h:\,
0x22C510) (0x2A)
  323  138810 [main] ls 1624 path_conv::check: this->path(h:\), has_acls(0)
  377  139187 [main] ls 1624 build_fh_pc: fh 0x61169E00
 5873  145060 [main] ls 1624 fhandler_disk_file::opendir: 0x692AB0 =
opendir (/cygdrive/h)
  890  145950 [main] ls 1624 geterrno_from_win_error: windows error 50 ==
errno 88
  370  146320 [main] ls 1624 fhandler_disk_file::readdir: 0 = readdir
(0x692AB0, 0x22C6D4) (.)
  721  147041 [main] ls 1624 geterrno_from_win_error: windows error 50 ==
errno 88
  416  147457 [main] ls 1624 normalize_posix_path: src /cygdrive/h/..
  345  147802 [main] ls 1624 normalize_posix_path: /cygdrive/ =
normalize_posix_path (/cygdrive/h/..)
  370  148172 [main] ls 1624 mount_info::conv_to_win32_path:
conv_to_win32_path (/cygdrive)
  385  148557 [main] ls 1624 set_flags: flags: binary (0x2)
  365  148922 [main] ls 1624 mount_info::conv_to_win32_path: src_path
/cygdrive, dst C:\cygwin\cygdrive, flags 0xA, rc 0
  381  149303 [main] ls 1624 lstat64: entering
  372  149675 [main] ls 1624 normalize_posix_path: src /cygdrive/h/..
  371  150046 [main] ls 1624 normalize_posix_path: /cygdrive/ =
normalize_posix_path (/cygdrive/h/..)
  378  150424 [main] ls 1624 mount_info::conv_to_win32_path:
conv_to_win32_path(/cygdrive)
  377  150801 [main] ls 1624 set_flags: flags: binary (0x2)
  372  151173 [main] ls 1624 mount_info::conv_to_win32_path: src_path
/cygdrive, dst C:\cygwin\cygdrive, flags 0xA, rc 0
  477  151650 [main] ls 1624 build_fh_pc: fh 0x6116A008
  283  151933 [main] ls 1624 stat_worker: (/cygdrive/h/.., 0x22C4E0, 1,
0x6116A008), file_attributes 17
  369  152302 [main] ls 1624 stat_worker: 0 = (/cygdrive/h/.., 0x22C4E0)
  376  152678 [main] ls 1624 fhandler_disk_file::readdir: 0 = readdir
(0x692AB0, 0x22C6D4) (..)
  747  153425 [main] ls 1624 geterrno_from_win_error: windows error 50 ==
errno 88
  376  153801 [main] ls 1624 fhandler_disk_file::readdir: 88 = readdir
(0x692AB0, 0x22C6D4) (***)
  377  154178 [main] ls 1624 __set_errno: dirent* readdir(DIR*):160 val 88
--------------------------------------------------------------------------

and 88, ENOSYS, `Function not implemented' is what's reported to the user.
 It may still be the case, of course, that some
Windows-permissions-related problem is at fault, but the fact remains that
1.5.18-1 still works, while nothing later than that does.  The problem
seems identical regardless of how the directory on the network-mounted
volume is referred to.

I'm happy to run further investigations: can anyone suggest a new angle to
try?

Thanks for any assistance,
-- 
SAm.

-- 
Academic Excellence at the Heart of Scotland.
The University of Stirling is a charity registered in Scotland, 
 number SC 011159.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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