Chuck wrote:

Attached files are output from "cygcheck -s -v -r > cygcheck.out", and
and an strace of a failed execution of "ls /cygdrive". By failed I mean
that the command produced no output.

That's funny.

The readdir() is cranking along, and reads c, g, h and k. Each of these consists of the sequence, e.g.:

  normalize_posix_path: src K:\
  normalize_win32_path: K:\ = normalize_win32_path (K:\)
  mount_info::conv_to_win32_path: conv_to_win32_path (K:)
  mount_info::conv_to_win32_path: src_path K:, dst K:, flags 0x0, rc 0
  symlink_info::check: not a symlink
  symlink_info::check: 0 = symlink.check (K:\, 0x22C210) (0x0)
  set_privilege: 1 = set_privilege ((token 6B0) SeChangeNotifyPrivilege, 1)
  path_conv::check: this->path(K:\), has_acls(0)
  fhandler_cygdrive::readdir: 0x22C9CC = readdir (0x6A1BE0) (k)

However, for his last drive (S:), I only see the trailing sequence

 normalize_posix_path: src S:\
 normalize_win32_path: S:\ = normalize_win32_path (S:\)
 mount_info::conv_to_win32_path: conv_to_win32_path (S:)

And that's it - it ends abruptly there (the second trace from conv_to_win32_path() is not present). So it seems to have died in that conv_to_win32_path() call.

Obviously something odd about that share. Chuck: can you tell if there's something unusual about the server that exports that share (as opposed to the other drives you have, like K: and G:)?


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

Reply via email to