Mail Archives: cygwin/2007/02/13/18:43:08
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/
- Raw text -