mingw-users Mailing List for MinGW - Minimalist GNU for Windows

> Date: Fri, 31 May 2013 16:04:25 -0400
> From: George Koehler <xke...@ne...>
> 
> Does your gdb target Windows? If so, then you might never get a
> backtrace, because your gdb only knows Windows calling conventions and
> not Linux calling conventions.

AFAIK, calling conventions have nothing to do with the OS, only with
the ABI used by the compiler.

> You might want an alternate gdb, to target Linux/i386 rather than
> Windows. I just don't know if there is an alternate gdb that can load
> Linux a.out format.

Actually, I think the OP wants a cross-GDB or should use remote
debugging.

On 05/29/13 04:34, fiveight wrote:
> So I decide to develop a programe to transform these a.out format file to PE format with debug information.

This might not be worth doing. The mingw gdb debugs i386 programs for
Windows, and knows nothing about Linux. Even if you can get the symbols
into gdb, some gdb features might not work.

Recently I used a FreeBSD/i386 gdb to debug a Linux/i386 program. (This
was no remote debug; FreeBSD can run Linux programs in its Linuxlator.)
This gdb warned about an unrecognized operating system (Linux), but I
was still able to debug at the assembly level, because this gdb knew the
instruction set (i386).

When gdb starts, it prints its target, such as
> This GDB was configured as "i386-marcel-freebsd".

Does your gdb target Windows? If so, then you might never get a
backtrace, because your gdb only knows Windows calling conventions and
not Linux calling conventions. If you can do any debugging at all, it is
only because your Windows and the remote Linux have the same instruction
set (i386). If you wanted to debug Linux/arm or Linux/powerpc, you would
have needed an alternate gdb.

You might want an alternate gdb, to target Linux/i386 rather than
Windows. I just don't know if there is an alternate gdb that can load
Linux a.out format.
--George Koehler

> Date: Fri, 31 May 2013 15:02:22 -0400
> From: Earnie Boyd <ea...@us...>
> 
> > But the deafening silence on these issues since I raised them (as well
> > as about a similar issue with 'struct dirent') makes me think that no
> > one here, including the maintainers, cares about binary compatibility.
> > I guess when the new runtime is out we will see who was right.
> 
> I'm working on a solution.  I'm in testing phase at the moment.  MinGW
> runtime 4.0 will supply the missing *32* functions either as an
> _CRTALIAS or a _CRT_INLINE depending on the function and the amount of
> coding required.  My testing is with both Win 7 and XP (xp on
> virtualbox vm).

Thank you!

On Fri, May 31, 2013 at 10:11 AM, Eli Zaretskii wrote:
>> Date: Fri, 31 May 2013 19:53:30 +0800
>> From: Yongwei Wu
>>
>> Recompiling solves the source-level compatibility. For binary
>> compatibility, Microsoft compilers link the functions to separate 32-
>> or 64-bit functions. E.g., time is mapped to either _time32 or
>> _time64, depending on whether _USE_32BIT_TIME_T is defined.
>
> But XP doesn't have _time32, so this is not a solution for MinGW,
> unless the MinGW runtime will provide _time32 (or abandon XP as the
> target platform).
>
> With 'stat' (and other functions that return or accept structures with
> time_t members), the binary compatibility would require similar
> functions in MinGW runtime _and_ 32-bit time_t type in the headers.
>
> But the deafening silence on these issues since I raised them (as well
> as about a similar issue with 'struct dirent') makes me think that no
> one here, including the maintainers, cares about binary compatibility.
> I guess when the new runtime is out we will see who was right.

I'm working on a solution.  I'm in testing phase at the moment.  MinGW
runtime 4.0 will supply the missing *32* functions either as an
_CRTALIAS or a _CRT_INLINE depending on the function and the amount of
coding required.  My testing is with both Win 7 and XP (xp on
virtualbox vm).

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

> Date: Fri, 31 May 2013 19:53:30 +0800
> From: Yongwei Wu <wuy...@gm...>
> 
> Recompiling solves the source-level compatibility. For binary
> compatibility, Microsoft compilers link the functions to separate 32-
> or 64-bit functions. E.g., time is mapped to either _time32 or
> _time64, depending on whether _USE_32BIT_TIME_T is defined.

But XP doesn't have _time32, so this is not a solution for MinGW,
unless the MinGW runtime will provide _time32 (or abandon XP as the
target platform).

With 'stat' (and other functions that return or accept structures with
time_t members), the binary compatibility would require similar
functions in MinGW runtime _and_ 32-bit time_t type in the headers.

But the deafening silence on these issues since I raised them (as well
as about a similar issue with 'struct dirent') makes me think that no
one here, including the maintainers, cares about binary compatibility.
I guess when the new runtime is out we will see who was right.

On 29 May 2013 10:49, Eli Zaretskii <el...@gn...> wrote:
>
> > Date: Tue, 28 May 2013 22:26:49 +0100
> > From: Keith Marshall <kei...@us...>
> >
> > On 28/05/13 17:49, Eli Zaretskii wrote:
> > > Btw, on a 64-bit Windows 7 system, if I step into the library function
> > > 'time' in a program compiled with MinGW runtime 3.20, I see that
> > > 'time' in msvcrt.dll jumps directly to 'time32', although
> > > _USE_32BIT_TIME_T was not used during the build.  Is this something
> > > that MinGW arranges for (and if so, how)?  Or is this msvcrt.dll in
> > > SysWOW64, which knows that the process is a 32-bit one, and therefore
> > > automatically redirects to a 32-bit function?
> >
> > But why would the size of time_t depend on processor word size?
>
> Backward compatibility?  It might not be about processor word size, it
> might be about the fact that on XP 'time' was a 32-bit function.

Recompiling solves the source-level compatibility. For binary
compatibility, Microsoft compilers link the functions to separate 32-
or 64-bit functions. E.g., time is mapped to either _time32 or
_time64, depending on whether _USE_32BIT_TIME_T is defined.

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

On Thu, May 30, 2013 at 1:54 PM, macropanther wrote:
> I reran my downloaded mingw-get-inst-20120426.exe after deleting the Windows
> HOME environment variable.  The install was on top of the one that was
> already there.  Worked like a champ.
>

All you had to do was remove the %HOME% variable and restart MSYS.
You didn't need to attempt to reinstall it.  Also you should consider
mingw-get-inst-*.exe a one time use only application.  You should use
mingw-get directly to update your system.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Turns out that I had just figured that out after readinga few dozen related
posts.  And, yes, I do have a %HOME% variable set to c:\.  I think I did
that years ago in an attempt to be lazy when typing long pathnames.  You
know, %HOME% is so much shorter thatn "C:\".  <grin>.

Thanks for the help!

Wes



--
View this message in context: http://mingw.5.n7.nabble.com/Invalid-HOME-after-installing-MinGW-tp31623p31625.html
Sent from the MinGW - User mailing list archive at Nabble.com.

I reran my downloaded mingw-get-inst-20120426.exe after deleting the Windows
HOME environment variable.  The install was on top of the one that was
already there.  Worked like a champ.  

Now, on to compiling gstreamer.  Only 19,383,556 headaches to go!

Thanks,

Wes



--
View this message in context: http://mingw.5.n7.nabble.com/Invalid-HOME-after-installing-MinGW-tp31623p31626.html
Sent from the MinGW - User mailing list archive at Nabble.com.

On Thu, May 30, 2013 at 12:30 PM, Wesley J. Miller wrote:
> Hello,
>
> MinGW, or, perhaps, more correctly, msys, thinks my home directory is /c and
> I don't have an msys/1.0/home directory at all..  This is, obviously, not
> right.
>
> I am Administrator on a WInXP machine (VM really).
> I installed (as Administrator) from mingw-get-inst-20120426.exe. During the
> install, I chose every option and elected to download latest packages.
> Installed to c:\MinGW.
>
> I checked my Start->Programs->Mingw->MinGW Shell properties. it is starting
> C:\MinGW\msys\1.0\msys.bat and the start-in directory is
> C:\MinGW\msys\1.0\bin.   Note I do not have an msys entry in my programs
> list.
>
> I have determined that / is C:\MinGW\msys\1.0.
>
> When I run  msys.bat I get a MinGW prompt.  Entering echo $HOME says /c. And
> there is no directory named /home. echo $USERNAME = Administrator and echo
> $LOGNAME = Administrator.
>
> Can someone tell me what I did to end up with no $HOME? Do I need to make a
> *nix user? Or perhaps remove MinGW and create a non-admin XP user and use
> that user to reinstall MinGW?

Unless HOME is set in your Windows environment when you first started
MSYS it should have created a /home/$USERNAME directory and set HOME
to it.  If HOME is an environment variable during the startup of MSYS
then that value is used.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Hello,

MinGW, or, perhaps, more correctly, msys, thinks my home directory is /c and I don't have an msys/1.0/home directory at all..  This is, obviously, not right.

I am Administrator on a WInXP machine (VM really).
I installed (as Administrator) from mingw-get-inst-20120426.exe. During the install, I chose every option and elected to download latest packages.  Installed to c:\MinGW.

I checked my Start->Programs->Mingw->MinGW Shell properties. it is starting C:\MinGW\msys\1.0\msys.bat and the start-in directory is C:\MinGW\msys\1.0\bin.   Note I do not have an msys entry in my programs list.

I have determined that / is C:\MinGW\msys\1.0.

When I run  msys.bat I get a MinGW prompt.  Entering echo $HOME says /c. And there is no directory named /home. echo $USERNAME = Administrator and echo $LOGNAME = Administrator.

Can someone tell me what I did to end up with no $HOME? Do I need to make a *nix user? Or perhaps remove MinGW and create a non-admin XP user and use that user to reinstall MinGW?


________________________________
CONFIDENTIALITY NOTE:

This e-mail and any attachments are confidential. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation.

On Thu, May 30, 2013 at 10:24 AM, Maik Heistermann wrote:
>
> Is there any way to solve this problem, e.g. by explicitely selecting
> other download mirrors? Any help is largely appreciated.
>

Unfortunately no.  At least not at the moment nor in the near future.
I do not know if Keith plans to address allowing a specification of
the download mirror or not.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Dear all,

I am trying to install MinGW/MSYS via mingw-get-inst - since a couple  
of days now.

At some point, the installation always reports a download error of sorts

mingw-get.exe: *** WARNING ***  
http://prdownloads.sourceforge.net/mingw/binutils-2.22-1-mingw32-bin.tar.lzma?download: opened with unexpected status: code =  
404
mingw-get.exe: *** WARNING *** please report this to the mingw-get maintainer
mingw-get.exe: *** ERROR *** Get package:  
http://prdownloads.sourceforge.net/mingw/binutils-2.22-1-mingw32-bin.tar.lzma?download: download  
failed
http://prdownloads.sourceforge.net/mingw/libgettextpo-0.18.1.1-2-mingw32-dll-0.tar.lzma?download
368.00 kB

The point at which these errors occur is not reproducable, but sooner  
or later it always happens. Similiar errors are occuring when using  
mingw-get from another computer to update an existing MinGW  
installation. From other posts I assume that this a a problem of  
SourceForge availability (see e.g.  
http://sourceforge.net/apps/trac/sourceforge/ticket/25576).

Is there any way to solve this problem, e.g. by explicitely selecting  
other download mirrors? Any help is largely appreciated.

Thanks a lot in advance!

Best regards,
Maik

Hi, All

I am using mingw on windows 7.
I build a.out format executable files on windows and run them on Linux 0.11.
I want to use GDB "add-symble-file" option to load these a.out format file to GDB on windows for remote debug, but get "File format not recognized."
So I decide to develop a programe to transform these a.out format file to PE format with debug information.
Can GDB load these PE format files successfully?

Thanks.
 				

　　　　　　　　fiveight
　　　　　　　　fiv...@to...
　　　　　　　　　　2013-05-29

2013/5/28 Paul Moore <p.f...@gm...>

> If you do an "All users" install, these probably end up in
> C:\Windows\System32...
>

It seems the case. Only when installed for current user is that the
Microsoft runtime gets placed in root of Python install.

In my installation for all users, C:\Windows\system32\python27.dll points
to that other big path to MSVCRT in Dependency Walker. If it wasn't for the
odd creation/modification dates, I would think the big path is created by
Python installer rather than Windows.


>
>
> On 28 May 2013 13:38, Oscar Benjamin <osc...@gm...> wrote:
>
>> On 28 May 2013 04:21, Renato Silva <br....@gm...> wrote:
>> >
>> > 2013/5/27 Oscar Benjamin <osc...@gm...>
>> >>
>> >> The python.org installers ship the relevant msvcrXX.dll and place it
>> >> in the root of the Python installation. It is then used by all
>> >> extension modules in that Python installation.
>> >
>> > I can't find any DLL named like that in my Python installation:
>>
>> These are fresh installs of Python 2.7, 3.2 and 3.3 using the MSI
>> installers from python.org (http://www.python.org/getit/):
>>
>> $ ls /q/tools/Python*/*.dll
>> /q/tools/Python27/msvcr90.dll
>> /q/tools/Python32/msvcr90.dll
>> /q/tools/Python33/msvcr100.dll
>> /q/tools/Python27/python27.dll
>> /q/tools/Python32/python32.dll
>> /q/tools/Python33/python33.dll
>>
>>
>> Oscar
>>
>>
>> ------------------------------------------------------------------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring
>> service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt!
>> http://p.sf.net/sfu/newrelic_d2d_may
>> _______________________________________________
>> MinGW-users mailing list
>> Min...@li...
>>
>> This list observes the Etiquette found at
>> http://www.mingw.org/Mailing_Lists.
>> We ask that you be polite and do the same.  Disregard for the list
>> etiquette may cause your account to be moderated.
>>
>> _______________________________________________
>> You may change your MinGW Account Options or unsubscribe at:
>> https://lists.sourceforge.net/lists/listinfo/mingw-users
>> Also: mailto:min...@li...
>> ?subject=unsubscribe
>>
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list
> etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe
>

> From: Renato Silva <br....@gm...>
> Date: Tue, 28 May 2013 19:30:16 -0300
> 
> > Run depends.exe on Python DLL, and you will see where it keeps those
> > libraries.  (They could be in the SxS directories somewhere.)
> >
> 
> This one? *C:\windows\winsxs\x86_**microsoft.vc90.crt_<lots of random chars>
> \MSVCR90.DLL*
> 
> Was that installed by Python?

Could be, if Python came with a redistributable MSVC libraries.

> Date: Tue, 28 May 2013 22:26:49 +0100
> From: Keith Marshall <kei...@us...>
> 
> On 28/05/13 17:49, Eli Zaretskii wrote:
> > Btw, on a 64-bit Windows 7 system, if I step into the library function
> > 'time' in a program compiled with MinGW runtime 3.20, I see that
> > 'time' in msvcrt.dll jumps directly to 'time32', although
> > _USE_32BIT_TIME_T was not used during the build.  Is this something
> > that MinGW arranges for (and if so, how)?  Or is this msvcrt.dll in
> > SysWOW64, which knows that the process is a 32-bit one, and therefore
> > automatically redirects to a 32-bit function?
> 
> But why would the size of time_t depend on processor word size?

Backward compatibility?  It might not be about processor word size, it
might be about the fact that on XP 'time' was a 32-bit function.

On 5/28/2013 9:26 PM, Keith Marshall wrote:
> But why would the size of time_t depend on processor word size?

It doesn't. Microsoft can pick any size for time_t, and it might not be 
the same size as int or void *.

Some people believe that 32-bit system has 32-bit time_t and 64-bit 
system has 64-bit time_t. That's wrong. It might be true for GNU/Linux, 
but it's not true for other systems. For example, OpenBSD/amd64 uses 
32-bit time_t with 64-bit pointers.

Microsoft has three different setups:
* 32-bit time_t with 32-bit pointers
* 64-bit time_t with 32-bit pointers
* 64-bit time_t with 64-bit pointers

See http://msdn.microsoft.com/en-US/library/1f4c8f33%28v=VS.80%29.aspx

--George Koehler

On Tue, May 28, 2013 at 6:30 PM, Renato Silva wrote:
>
> This one? C:\windows\winsxs\x86_microsoft.vc90.crt_<lots of random
> chars>\MSVCR90.DLL
>
> Was that installed by Python? Date of creation/modification is 2010, for
> folder too.
>

Or perhaps by Microsoft itself.  winsxs is Windows side-by-side
distribution mechanism.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

2013/5/28 Eli Zaretskii <el...@gn...>

> > From: Renato Silva <br....@gm...>
> > Date: Tue, 28 May 2013 00:21:12 -0300
> >
> > 2013/5/27 Oscar Benjamin <osc...@gm...>
> >
> > > The python.org installers ship the relevant msvcrXX.dll and place it
> > > in the root of the Python installation. It is then used by all
> > > extension modules in that Python installation.
> > >
> >
> > I can't find any DLL named like that in my Python installation:
> >
> > $ python.exe --version
> > Python 2.7.3
> >
> > $ type python.exe
> > python.exe is hashed
> (/windows/Programs/Desenvolvimento/Python/python.exe)
> >
> > $ type find.exe
> > find.exe is hashed (/bin/find.exe)
> >
> > $ find.exe  /windows/Programs/Desenvolvimento/Python -iname '*msvcr*'
> > $ # nothing found
>
> Run depends.exe on Python DLL, and you will see where it keeps those
> libraries.  (They could be in the SxS directories somewhere.)
>

This one? *C:\windows\winsxs\x86_**microsoft.vc90.crt_<lots of random chars>
\MSVCR90.DLL*

Was that installed by Python? Date of creation/modification is 2010, for
folder too.



>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list
> etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe
>

On 28/05/13 17:49, Eli Zaretskii wrote:
> Btw, on a 64-bit Windows 7 system, if I step into the library function
> 'time' in a program compiled with MinGW runtime 3.20, I see that
> 'time' in msvcrt.dll jumps directly to 'time32', although
> _USE_32BIT_TIME_T was not used during the build.  Is this something
> that MinGW arranges for (and if so, how)?  Or is this msvcrt.dll in
> SysWOW64, which knows that the process is a 32-bit one, and therefore
> automatically redirects to a 32-bit function?

But why would the size of time_t depend on processor word size?  AIUI, 
the move to 64-bit time_t is advance planning, to accommodate overflow 
in the 32-bit time_t which will occur in about 25 years from now.

-- 
Regards,
Keith.

> Date: Tue, 28 May 2013 15:09:22 -0400
> From: Earnie Boyd <ea...@us...>
> 
> On Tue, May 28, 2013 at 12:49 PM, Eli Zaretskii wrote:
> >> Date: Tue, 28 May 2013 18:59:20 +0300
> >> From: Eli Zaretskii <el...@gn...>
> >>
> >> My reading of the patch is that time_t will by default be a 64-bit
> >> type, and that the only way to get a 32-bit time_t is to define
> >> _USE_32BIT_TIME_T, which will only work on Vista and later.  Is that
> >> right?
> >
> > Btw, on a 64-bit Windows 7 system, if I step into the library function
> > 'time' in a program compiled with MinGW runtime 3.20, I see that
> > 'time' in msvcrt.dll jumps directly to 'time32', although
> > _USE_32BIT_TIME_T was not used during the build.  Is this something
> > that MinGW arranges for (and if so, how)?  Or is this msvcrt.dll in
> > SysWOW64, which knows that the process is a 32-bit one, and therefore
> > automatically redirects to a 32-bit function?
> 
> Mingwrt 3.20 defaulted to 32bit time_t based on the value of __MSVCRT_VERSION__.

Right, but I was asking about the function time32, which is not
mentioned in 3.20.

> I am trying to overcome the lameness of having various versions of the
> default system runtime depending on OS.  I have shortened
> __MSVCRT_VERSION__ to MSVCRT_VERSION since I mean for it to be based
> on which OS is being supported (I.E. which version of MSVCRT.DLL)
> rather than which library is being used.

Yes, I understand.  What I didn't find was a way to get a 32-bit
time_t in a program that would run on XP and newer systems.  With
3.20, we have that in the default build, but I see no such way, even a
non-default one, in the patches to which you pointed.  Maybe I'm
missing something.

On Tue, May 28, 2013 at 12:49 PM, Eli Zaretskii wrote:
>> Date: Tue, 28 May 2013 18:59:20 +0300
>> From: Eli Zaretskii <el...@gn...>
>>
>> My reading of the patch is that time_t will by default be a 64-bit
>> type, and that the only way to get a 32-bit time_t is to define
>> _USE_32BIT_TIME_T, which will only work on Vista and later.  Is that
>> right?
>
> Btw, on a 64-bit Windows 7 system, if I step into the library function
> 'time' in a program compiled with MinGW runtime 3.20, I see that
> 'time' in msvcrt.dll jumps directly to 'time32', although
> _USE_32BIT_TIME_T was not used during the build.  Is this something
> that MinGW arranges for (and if so, how)?  Or is this msvcrt.dll in
> SysWOW64, which knows that the process is a 32-bit one, and therefore
> automatically redirects to a 32-bit function?

Mingwrt 3.20 defaulted to 32bit time_t based on the value of __MSVCRT_VERSION__.

MSVC depends on its MSVCR## library and doesn't consider the version.

I am trying to overcome the lameness of having various versions of the
default system runtime depending on OS.  I have shortened
__MSVCRT_VERSION__ to MSVCRT_VERSION since I mean for it to be based
on which OS is being supported (I.E. which version of MSVCRT.DLL)
rather than which library is being used.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

> Date: Tue, 28 May 2013 18:59:20 +0300
> From: Eli Zaretskii <el...@gn...>
> 
> My reading of the patch is that time_t will by default be a 64-bit
> type, and that the only way to get a 32-bit time_t is to define
> _USE_32BIT_TIME_T, which will only work on Vista and later.  Is that
> right?

Btw, on a 64-bit Windows 7 system, if I step into the library function
'time' in a program compiled with MinGW runtime 3.20, I see that
'time' in msvcrt.dll jumps directly to 'time32', although
_USE_32BIT_TIME_T was not used during the build.  Is this something
that MinGW arranges for (and if so, how)?  Or is this msvcrt.dll in
SysWOW64, which knows that the process is a 32-bit one, and therefore
automatically redirects to a 32-bit function?

On Mon, May 27, 2013 at 8:25 PM, Hurcan Solter wrote:
> Hah , I was about the reiterate I've already tried restarting msys
> (that is kill all sh.exe instances) but after your post decided to recheck
> task manager and found a cat.exe still running (orphaned is the correct term
> I guess)
> after killing it I was able to mount the directory from the terminal and it
> was there after
> the restart.I am guessing my previous attempts spawned(forked?) the same
> process anew without
> initialization.Asking out of curiosity, is that the case?
>
> The Doh moment was enlightening :). Thanks a lot.

Taking a guess I would think that it is probable that the thread
watching the /etc directory for changes failed (or didn't even
trigger) because of the orphaned process.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd