On Jul 14 13:16, Larry Hall (Cygwin) wrote:
Lee Maschmeyer wrote:
OK, so perhaps your problem and the Windows path shown by 'cygcheck'
are
two
different issues.
My problem is _precisely_ the Windows path shown by cygcheck. Everything
_except_ Cygwin (as shown by cygcheck) is correct as far as I can see.
Actually, you showed me the path that 'bash' has and it contains no
reference to the 'a' drive in any form. Since you run from a shell,
this is the path that's important. It may be coincidence or it may
be one externalization of the bug you're seeing but the Windows path
shown by 'cygcheck' has no bearing on the path that the shell sees.
Said another way, if 'cygcheck' has a bug that ends up showing you a
faulty path here, that would have no effect on anything else Cygwin.
So what we've covered so far doesn't provide a clear reason for the
behavior you're seeing.
I'm back to not being sure why you're seeing accesses on
your floppy drive. Maybe if you straced a simple operation, you might
be
able to tell us who, what, when, why, and/or how the floppy drive gets
accessed.
Attached is the output of the command:
strace -o strace_ls.log ls 1.7-log.txt
I don't think it tells us anything we didn't know. Cygwin, down under
the
hood, thinks Windows is on a: but all its variables show that it's on
c:,
as do Windows variables.
To me this suggests that there could be a problem with getwinenv() but
I can't say more than that at the moment.
It's not in getwinenv afaics, but I don't know what the actual problem
is so far. It has something to do with the existance of the /a, /c etc
mounts, though. For now, removing the /a mount from /etc/fstab will help
to get back to speed. I'll try to figure out the cause of this problem.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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/