Subject: RE: SOLVED! (but got more problems...) (was: HUGE filesystem PROBLEM (too big to be true))
From: [email-masked] (Zow Terry Brugger)

20 Feb 1998 16:13:53 -0800
Message-ID: <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: "'banders'" <[email-masked]>,
        Nicola Bernardini
	 <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
        "[email-masked]"
	 <[email-masked]>

-----Original Message-----
From:	banders

only way I know is to remove the offinding usr directory from your
root. The one on the root directory masks the mounted one.
That's one cygnus ought to look at.

What would be really nice is if GNU-Win32 could concationate the contents 
of the two. . . Any thoughts on what it would take to do that? If someone 
could point me to where that should be handled, I might have a look. . .

	Bart

Terry

Nicola Bernardini wrote:
>
> Thanks to everybody in the list to help me out in solving the problem
> of removing 'con.xx' type files. In particular, I'd like to thank
> Sam Liddicott, Paul Ashton, Rob Warner, Benjamin Riefenstahl,
> Chris Faylor, Ralf Meyer, Ron Parker, Steve Newcomb who all came
> up with different ideas and suggestions. The simplest solution was
> to
>
> del \\.\c:\dir\con.c
>
> from the dos console.
>
> rm //./c:/dir/con.c
>
> worked for me with cygnus too. Thanks.
>
> In the process, I got stuck with several other problems which I'll
> list below (maybe you have an answer for these too...)
>
> 1) while trying of removing things, I got stuck with serveral hung 
processes
>    who would not go away. My situation was:
>
> TTY   PID  PPID  PGID  WIN32-PID  UID COMMAND
> 00   1000  1000     0         66  500 
c:\gnuwin32\b18\H-i386-cygwin32\local\sbin\inetd.exe
> -1   5678  1035  5678        366  500 
C:\gnuwin32\b18\H-i386-cygwin32\local\libexec\in.telnetd
> 02   1013  1013     0        171  500 
c:\gnuwin32\b18\H-i386-cygwin32\local\sbin\inetd.exe
> 03   1035  1035     0        168  500 
c:\gnuwin32\b18\H-i386-cygwin32\local\sbin\inetd.exe
> 05   5679  5678  5679        387 1007 c:\bin\bash.exe
> 01   5596     1     0        453  500 
c:\gnuwin32\b18\H-i386-cygwin32\bin\gzip.exe
> 04   4741     1  4741        588 1007 c:\bin\bash.exe
> 01I  5653     1  5653        256 1007 
c:\gnuwin32\b18\H-i386-cygwin32\local\bin\cp.exe
> 03   5292  5292     0        249 1007 c:\user\nicb\gnu-sources\fileuti  
ls-3.16\src\rm.exe
> 03O  5468  5468     0        502 1007 
c:\user\nicb\gnu-sources\fileutils-3.16\src\rm.exe
> 04I  5478  4741  5478        554 1007 
c:\gnuwin32\b18\H-i386-cygwin32\local\bin\less.exe
> 05   5685  5679  5685        412 1007 
c:\gnuwin32\b18\H-i386-cygwin32\bin\ps.exe
>
> and when I tried to kill 5653 5292 5468 5478 with
>
> kill -9 5653 5292 5468 5478
>
> I would get
>
> bash: kill: (5292) - No such pid
> bash: kill: (5468) - No such pid
>
> The other processes would simply stay alive, silently. When I tried to
> access these processes from the task manager, Windows NT hung!
>
> 2) Since I had to reboot the machine and restart inetd, I noticed that
>    when I start inetd as a process my mount table gets reset to default
>
> 3) another problem with mount: here's my usual mount table
>
> Device           Directory           Type        Flags
> c:\gnuwin32\b18\H-i386-cygwin32 /usr                native 
     no-mixed,text=binary
> \\.\tape1:       /dev/st1            native      no-mixed,text!=binary
> \\.\tape0:       /dev/st0            native      no-mixed,text!=binary
> \\.\b:           /dev/fd1            native      no-mixed,text!=binary
> \\.\a:           /dev/fd0            native      no-mixed,text!=binary
> c:               /                   native      no-mixed,text=binary
>
>    now I also happen to have a physical /usr directory which has nothing
>    to do with the mounted /usr one (that's a very convenient feature of
>    mount, I find). In this situation, when I ls /usr I see the mounted
>    directory, when I ls usr (no slash) from root I see the physical
>    directory. You can imagine that this creates quite a mess with tar
>    packages...
>
> Has anybody got clues?
>
> Thanks again,
>
> Nicola
> ------------------------------------------------------------------------
> Nicola Bernardini
> E-mail: [email-masked]
>
> Re graphics: A picture is worth 10K words -- but only those to describe
> the picture.  Hardly any sets of 10K words can be adequately described
> with pictures.
>
> -
> For help on using this list (especially unsubscribing), send a message to
> "[email-masked]" with one line of text: "help".

--
Bartlee A. Anderson     System Test (Interfaces-Tools-Automation-ISDN)
Rockwell International                    Electronic Commerce Division
300 Bauman Ct.                                [email-masked]
MS 933-605      Opinions my own, not Rockwell's   VOICE (630) 227-8975
Wood Dale, IL 60191                               FAX   (630) 227-9771
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".