1.7 constantly accesses floppy drive

Lee Maschmeyer lee_maschmeyer@wayne.edu
Mon Jul 14 20:25:00 GMT 2008


Thanks Corinna. Commenting out the entry for a: fixed the problem. Of 
course, this means I can't access files on the floppy as /a/file like I can 
/c/file. But at least it works now.

Have fun,

-- 
Lee Maschmeyer
Computing Center Services
Computing and Information Technology
Wayne State University
Detroit, Michigan, USA
----- Original Message ----- 
From: "Corinna Vinschen" <corinna-cygwin@cygwin.com>
To: <cygwin@cygwin.com>
Sent: Monday, July 14, 2008 13:50
Subject: Re: 1.7 constantly accesses floppy drive


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



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



More information about the Cygwin mailing list