Re: Calling cygpath from find exec?

[Duncan Roe]

On Mon, Nov 23, 2015 at 02:23:33PM -0700, Eric Blake wrote:
> On 11/23/2015 01:45 PM, Matt D. wrote:
> > Is there a reason why these produce different results?
> >
> > find . -exec cygpath -wa {} \;
> > find . -exec echo $(cygpath -wa {}) \;
>
> Incorrect quoting.  You are invoking:
>
> find . -exec echo c:\cygwin\home\you\{} \;
>
> (or whatever ./{} resolves to), instead of one cygpath per name found by
> find.
>
> >
> > I have to do this which is much slower:
> > find . -exec bash -c 'echo $(cygpath -wa {})' \;
> >
>
> This indeed quotes things so that cygpath is now invoked once per file,
> but at the expense of an additional bash per file as well.
>
> Why not just:
>
> find . -exec cygpath -wa {} +
>
> since cygpath handles more than one file in an invocation (that is,
> using '-exec {} +' rather than '-exec {} \;' is generally faster).
>
I would be using xargs. Especially under /cygdrive, the "-print0 / xargs -0"
combination takes care of spaces and other nasties in file names.

find . -print0 | xargs -0 cygpath -wa

For utilities that only accept one argument, you can use xargs -n1 -0; you
still get the benefit of -print0.

Cheers ... Duncan.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2

[David Macek]

On 1. 12. 2015 18:40, David Macek wrote:
> On 1. 12. 2015 15:01, Corinna Vinschen wrote:
>> On Dec  1 21:07, nu774 wrote:
 There must be a bug in the new CMD somewhere.  But, anyway, I'll look
 into it when I finally managed to update my W10 test machine.
>>>
>>> No, cmd.exe is just an example. Any 32bit process can be an trigger.
>>> I guess something has changed in TH2 kernel regarding process memory
>>> management or something that interferes cygwin's fork().
>>
>> If that only happens w/ 64 bit Cygwin started from a 32 bit parent, then
>> there's some foul-up in the WOW64 layer in terms of starting 64 bit
>> processes, perhaps.  Sigh, it's a rather unexpected change after it
>> worked fine for so long :(
> 
> Yup. I can confirm.

Just for the record, we did some debugging over IRC and it seems it's an issue 
with WOW64 where the stack in the first 64-bit process is offset for some 
reason.

Citing Corinna: "I wonder if we have to resurrect the old wow64_respawn_process 
function for this border case"

-- 
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Calling cygpath from find exec?

[Eric Blake]

On 12/01/2015 01:43 PM, Duncan Roe wrote:

>> Why not just:
>>
>> find . -exec cygpath -wa {} +
>>
>> since cygpath handles more than one file in an invocation (that is,
>> using '-exec {} +' rather than '-exec {} \;' is generally faster).
>>
> I would be using xargs. Especially under /cygdrive, the "-print0 / xargs -0"
> combination takes care of spaces and other nasties in file names.

But so does 'find ... -exec ... {} +', and with one fewer process.
xargs is fine when you need it, but here, you don't.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Setup suggestion: Check for running processes before uninstalling anything.

[Andrey Repin]

Greetings, All!

I just got a hard case of stupidity...
Started Cygwin setup before checking if anything is running Cygwin.
Guess, what? It indeed did run. However, setup managed to uninstall mintty
before telling me that there's ssh-pageant running in the background.
I had to dig up and start shell manually to gracefully shutdown the agent.

I think it would be pretty nice of the Setup to check for running processes
before starting to make changes to the environment. IMHO.


-- 
With best regards,
Andrey Repin
Wednesday, December 2, 2015 02:08:30

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Persistent CYGWIN/X server taskbar button with urxvt in CYGWIN-64, not rxvt in CYGWIN-32. Why?

[John J Ottusch]

> I think this is not a problem with the X server, but with the Cygwin 
run 
> utility, which is supposed to run the .bat file with a hidden console.

> See [1] a previous discussion of this problem.

> I've built an x86_64 run.exe with that patch applied and uploaded it 
at 
> [2]. Perhaps you could try that and see if it improves things.

> [1] http://cygwin.com/ml/cygwin-xfree/2012-08/msg0.html
> [2] ftp://cygwin.com/pub/cygwinx/x86_64/run.exe

-- 

Makes sense that it could be run.exe behavior.

However, the version of run.exe from [2] (which is 220K in size vs. 68K 
for the original version ?!?) does not seem to do anything. Running it 
from a CMD window with urxvtermX.bat as the argument does not produce an 
error message, a urxvt term, nothing.

BTW, I made an effort to give both versions of run.exe (I renamed the 
new one runX.exe) the same ownership and permissions, but to no avail.

Am I missing something essential?

jjo

P.S. My apologies if this message is not properly threaded. I see how 
one can post an original message from 'http://post.gmane.org/post.php?
group=gmane.os.cygwin.xfree', but not how one goes about replying to a 
previously posted message.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2

[David Macek]

On 1. 12. 2015 15:01, Corinna Vinschen wrote:
> On Dec  1 21:07, nu774 wrote:
>>> There must be a bug in the new CMD somewhere.  But, anyway, I'll look
>>> into it when I finally managed to update my W10 test machine.
>>
>> No, cmd.exe is just an example. Any 32bit process can be an trigger.
>> I guess something has changed in TH2 kernel regarding process memory
>> management or something that interferes cygwin's fork().
> 
> If that only happens w/ 64 bit Cygwin started from a 32 bit parent, then
> there's some foul-up in the WOW64 layer in terms of starting 64 bit
> processes, perhaps.  Sigh, it's a rather unexpected change after it
> worked fine for so long :(

Yup. I can confirm.

-- 
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature

RE: chere Bash Prompt Here window closes immediately

[Matt Seitz (matseitz)]

>From: Dave Kilroy [mailto:kilr...@googlemail.com] 

>>On 23/10/2015 16:16, Matt Seitz (matseitz) wrote:
>> When I right click a folder in Windows Explorer and select "Bash 
>> Prompt Here", a window opens briefly and then closes immediately.  

> I suspect this may be due to the use of %DISPLAY% (which I don't recall). I 
> see that in your environment this is set to ":1.0"
> What happens if you run the following from cmd:

Thanks for the debugging steps.  Unfortunately, I already worked around the 
problem by cleaning up a lock file so that the Xwin server would start as 
":0.0" instead of ":1.0".  If I run into the problem again, I will try your 
debugging steps.

> Also, I presume the X server is already running?

Yes, the X server was already running.  


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2

[Rob van Eijk]

Op 1-12-2015 om 17:40 schreef David Macek:
> On 1. 12. 2015 15:01, Corinna Vinschen wrote:
>> On Dec  1 21:07, nu774 wrote:
 There must be a bug in the new CMD somewhere.  But, anyway, I'll look
 into it when I finally managed to update my W10 test machine.
>>>
>>> No, cmd.exe is just an example. Any 32bit process can be an trigger.
>>> I guess something has changed in TH2 kernel regarding process memory
>>> management or something that interferes cygwin's fork().
>>
>> If that only happens w/ 64 bit Cygwin started from a 32 bit parent, then
>> there's some foul-up in the WOW64 layer in terms of starting 64 bit
>> processes, perhaps.  Sigh, it's a rather unexpected change after it
>> worked fine for so long :(
> 
> Yup. I can confirm.
> 

I upgraded today to Windows 10 v1511. I ran into the same problem. I
renamed my cygwin root directory (64 bit) and installed a 32 bit version
of cygwin. The fork problem does not appear on the 32 bit version.

In conclusion, I confirm that the issue appears when running a 32 bit
version from a 64 bit cygwin. It does not appear when running a 32 bit
app from a 32 bit cygwin.

PS: my test applicatin is notepad++ with the nppexec plugin, which I use
to power up the make command in a cygwin shell.

mvg::Rob

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: setup-x86 unattended mode: crash when invoked from a dos console.

[Corinna Vinschen]

Hi Francis,

On Nov 30 23:59, Francis ANDRE wrote:
> Hi
> 
> The following set-x86.exe command in unattended mode crashes on Win7
> 
> C:\Users\FrancisANDRE>c:\cygwin\bin\uname.exe -a
> CYGWIN_NT-6.1-WOW idefix 2.3.1(0.291/5/3) 2015-11-14 12:42 i686 Cygwin
> 
> C:\Users\FrancisANDRE>c:\cygwin\setup-x86.exe -B -D -q -n  -d -R cygwin -s
> http://mirror.csclub.uwaterloo.ca/cygwin  -P unzip

The crash is not nice and I'm just looking into that, but the path you
specify with the -R option is supposed to be an absolute DOS path, e.g.
C:/cygwin.  Please try this, it should get you further.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpmRMdtRd7Xs.pgp
Description: PGP signature

Re: grep couldn't find expression if i specify short path

[Михаил Гаврилов]

cygcheck.out
Description: Binary data
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2

[nu774]

After upgrading to Windows 10 TH2 (ver 1511, build 10586), any attempt
to launch a cygwin64 process from 32bit native app (for example,
C:\windows\syswow64\cmd.exe) *always* results in a fork error.

To be precise, I can execute 64bit bash.exe from 32bit cmd.exe.
However, this bash process never succeeds in forking a child (ls or
something).
Also, I cannot launch 64bit mintty.exe from 32bit cmd.exe. It always
fails in a error dialog saying that:

mintty: could not detach from caller
Try '--help' for more information.

When launching from 64bit app, this issue doesn't happen.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: control-R broken in bash (__fzf_history__)

[Adam Dinwoodie]

On Mon, Nov 30, 2015 at 12:36:16PM -0600, David Blackstone wrote:
> Recently I found that the behavior of control-R in bash had changed.
> The key binding has been modified by the fzf-bash package to activate
> the fzf fuzzy search program.  The first noticeable result is that
> pressing control-R displays a message with the string
> $(__fzf_history__) followed by a listing of history commands, instead
> of searching through command-line history the way control-R worked
> before.
> 
> I update my cygwin install frequently installing all new packages.  So
> far the only way I've found to deactivate this is to uninstall the
> fzf-bash package, but that is going to make my updates more
> complicated as I'll have to click to install all packages then
> manually deselect that package before proceeding.
> 
> Is there a way to disable the fzf bash keybinding without having to
> uninstall the package?  Is there any chance this package could be
> modified to not be turned on without being explicitly enabled in the
> user's shell configuration files, so this radical environment change
> doesn't happen just from installing the package?

fzf-bash installs a script into /etc/profile.d so that, once installed,
the key bindings are available.  I think it's reasonable to assume that
someone installing the package would want the functionality -- your
desire to install all the packages but not have all the function
notwithstanding -- and as such I'm not willing to clobber the package so
that people installing it need to do extra work to be able to use it.

If you want to keep installing everything but want to maintain existing
Ctrl-R behaviour, your best bet is to explicitly bind Ctrl-R to the Bash
reverse-search function.  You can do this by adding the following line
to your .bashrc, which (unless you're doing something odd) is executed
after the contents of /etc/profile.d:

bind '\C-r:reverse-search-history'

Adam

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2

[nu774]

There must be a bug in the new CMD somewhere.  But, anyway, I'll look
into it when I finally managed to update my W10 test machine.


No, cmd.exe is just an example. Any 32bit process can be an trigger.
I guess something has changed in TH2 kernel regarding process memory 
management or something that interferes cygwin's fork().



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: setup-x86 unattended mode: crash when invoked from a dos console.

[Francis ANDRE]

Hi Corinna

Le 01/12/2015 10:54, Corinna Vinschen a écrit :

Hi Francis,

On Nov 30 23:59, Francis ANDRE wrote:

Hi

The following set-x86.exe command in unattended mode crashes on Win7

C:\Users\FrancisANDRE>c:\cygwin\bin\uname.exe -a
CYGWIN_NT-6.1-WOW idefix 2.3.1(0.291/5/3) 2015-11-14 12:42 i686 Cygwin

C:\Users\FrancisANDRE>c:\cygwin\setup-x86.exe -B -D -q -n  -d -R cygwin -s
http://mirror.csclub.uwaterloo.ca/cygwin  -P unzip

The crash is not nice and I'm just looking into that, but the path you
specify with the -R option is supposed to be an absolute DOS path, e.g.
C:/cygwin.  Please try this, it should get you further.
Thanks for the tips.. It avoids the crash. By the way, what is the 
option to set in order to avoid the Progress popup window?



Thanks,
Corinna




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2

[Corinna Vinschen]

On Dec  1 19:27, nu774 wrote:
> After upgrading to Windows 10 TH2 (ver 1511, build 10586), any attempt
> to launch a cygwin64 process from 32bit native app (for example,
> C:\windows\syswow64\cmd.exe) *always* results in a fork error.
> 
> To be precise, I can execute 64bit bash.exe from 32bit cmd.exe.
> However, this bash process never succeeds in forking a child (ls or
> something).
> Also, I cannot launch 64bit mintty.exe from 32bit cmd.exe. It always
> fails in a error dialog saying that:
> 
> mintty: could not detach from caller
> Try '--help' for more information.
> 
> When launching from 64bit app, this issue doesn't happen.

I don't have a W10 ver 1511 yet, but even then it's hard to see that
this may be Cygwin's fault.  It worked so far with all versions of
Windows since XP 64, including the pre-1511 W10.

There must be a bug in the new CMD somewhere.  But, anyway, I'll look
into it when I finally managed to update my W10 test machine.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpK0FUE7HH9I.pgp
Description: PGP signature

Re: [PATCH v2] Introduce the 'usertemp' filesystem type

[Johannes Schindelin]

Hi Corinna,

On Tue, 1 Dec 2015, Corinna Vinschen wrote:

> On Dec  1 15:02, Johannes Schindelin wrote:
> > * mount.cc (mount_info::from_fstab_line): support mounting the
> > current user's temp folder as /tmp/. This is particularly
> > useful a feature when Cygwin's own files are write-protected.
> > 
> > * pathnames.xml: document the new usertemp file system type
> 
> patch looks good.  We just have to wait for the ok in terms of the
> copyright assignment.  Might take a day or two.

Sure thing. Thank you for your patience!

Ciao,
Johannes

[PATCH v2] Introduce the 'usertemp' filesystem type

[Johannes Schindelin]

* mount.cc (mount_info::from_fstab_line): support mounting the
current user's temp folder as /tmp/. This is particularly
useful a feature when Cygwin's own files are write-protected.

* pathnames.xml: document the new usertemp file system type

Detailed explanation:

In the context of Windows, there is a per-user directory for temporary
files, by default specified via the environment variable %TEMP%. Let's
allow to use that directory for our /tmp/ directory.

With this patch, we introduce the special filesystem type "usertemp":
By specifying

none /tmp usertemp binary,posix=0 0 0

in /etc/fstab, the /tmp/ directory gets auto-mounted to the directory
specified by the %TEMP% variable.

This feature comes handy in particularly in scenarios where the
administrator might want to write-protect the entire Cygwin directory
yet still needs to allow users to write into the /tmp/ directory.
This is the case in the context of Git for Windows, where the
Cygwin (MSys2) root directory lives inside C:\Program Files and hence
/tmp/ would not be writable otherwise.

Signed-off-by: Johannes Schindelin 
---
 winsup/cygwin/include/sys/mount.h |  3 ++-
 winsup/cygwin/mount.cc| 21 +
 winsup/doc/pathnames.xml  | 24 +---
 3 files changed, 44 insertions(+), 4 deletions(-)

diff --git a/winsup/cygwin/include/sys/mount.h 
b/winsup/cygwin/include/sys/mount.h
index 458cf80..ec92794 100644
--- a/winsup/cygwin/include/sys/mount.h
+++ b/winsup/cygwin/include/sys/mount.h
@@ -44,7 +44,8 @@ enum
   MOUNT_DOS =  0x4,/* convert leading spaces and trailing
   dots and spaces to private use area 
*/
   MOUNT_IHASH =0x8,/* Enforce hash values for 
inode numbers */
-  MOUNT_BIND = 0x10/* Allows bind syntax in fstab file. */
+  MOUNT_BIND = 0x10,   /* Allows bind syntax in fstab file. */
+  MOUNT_USER_TEMP =0x20/* Mount the user's $TMP. */
 };
 
 int mount (const char *, const char *, unsigned __flags);
diff --git a/winsup/cygwin/mount.cc b/winsup/cygwin/mount.cc
index c04805b..fc080c9 100644
--- a/winsup/cygwin/mount.cc
+++ b/winsup/cygwin/mount.cc
@@ -1172,6 +1172,8 @@ mount_info::from_fstab_line (char *line, bool user)
   unsigned mount_flags = MOUNT_SYSTEM | MOUNT_BINARY;
   if (!strcmp (fs_type, "cygdrive"))
 mount_flags |= MOUNT_NOPOSIX;
+  if (!strcmp (fs_type, "usertemp"))
+mount_flags |= MOUNT_IMMUTABLE;
   if (!fstab_read_flags (, mount_flags, false))
 return true;
   if (mount_flags & MOUNT_BIND)
@@ -1196,6 +1198,22 @@ mount_info::from_fstab_line (char *line, bool user)
   slashify (posix_path, cygdrive, 1);
   cygdrive_len = strlen (cygdrive);
 }
+  else if (!strcmp (fs_type, "usertemp"))
+{
+  WCHAR tmp[PATH_MAX + 1];
+
+  if (GetTempPathW (PATH_MAX, tmp))
+   {
+ tmp_pathbuf tp;
+ char *mb_tmp = tp.c_get ();
+ sys_wcstombs (mb_tmp, PATH_MAX, tmp);
+
+ mount_flags |= MOUNT_USER_TEMP;
+ int res = mount_table->add_item (mb_tmp, posix_path, mount_flags);
+ if (res && get_errno () == EMFILE)
+   return false;
+   }
+}
   else
 {
   int res = mount_table->add_item (native_path, posix_path, mount_flags);
@@ -1653,6 +1671,9 @@ fillout_mntent (const char *native_path, const char 
*posix_path, unsigned flags)
   if (flags & (MOUNT_BIND))
 strcat (_my_tls.locals.mnt_opts, (char *) ",bind");
 
+  if (flags & (MOUNT_USER_TEMP))
+strcat (_my_tls.locals.mnt_opts, (char *) ",usertemp");
+
   ret.mnt_opts = _my_tls.locals.mnt_opts;
 
   ret.mnt_freq = 1;
diff --git a/winsup/doc/pathnames.xml b/winsup/doc/pathnames.xml
index 9077303..9941633 100644
--- a/winsup/doc/pathnames.xml
+++ b/winsup/doc/pathnames.xml
@@ -74,9 +74,10 @@ doesn't matter if you write FAT into this 
field even if
 the filesystem is NTFS.  Cygwin figures out the filesystem type and its
 capabilities by itself.
 
-The only exception is the file system type cygdrive.  This type is
-used to set the cygdrive prefix.  For a description of the cygdrive prefix
-see 
+The only two exceptions are the file system types cygdrive and usertemp.
+The cygdrive type is used to set the cygdrive prefix.  For a description of
+the cygdrive prefix see , for a description of
+the usertemp file system type see 
 
 The fourth field describes the mount options associated
 with the filesystem.  It is formatted as a comma separated list of
@@ -354,6 +355,23 @@ independently from the current cygdrive prefix:
 
 
 
+The usertemp file system type
+
+On Windows, the environment variable TEMP specifies
+the location of the temp folder.  It serves the same purpose as the /tmp/
+directory in Unix systems.  In contrast to /tmp/, it is by default a
+different folder for every Windows.  By using the special purpose usertemp
+file 

Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2

[Corinna Vinschen]

On Dec  1 21:07, nu774 wrote:
> >There must be a bug in the new CMD somewhere.  But, anyway, I'll look
> >into it when I finally managed to update my W10 test machine.
> 
> No, cmd.exe is just an example. Any 32bit process can be an trigger.
> I guess something has changed in TH2 kernel regarding process memory
> management or something that interferes cygwin's fork().

If that only happens w/ 64 bit Cygwin started from a 32 bit parent, then
there's some foul-up in the WOW64 layer in terms of starting 64 bit
processes, perhaps.  Sigh, it's a rather unexpected change after it
worked fine for so long :(


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpQczuUjqRao.pgp
Description: PGP signature

Re: setup-x86 unattended mode: crash when invoked from a dos console.

[Corinna Vinschen]

On Dec  1 12:18, Francis ANDRE wrote:
> Hi Corinna
> 
> Le 01/12/2015 10:54, Corinna Vinschen a écrit :
> >Hi Francis,
> >
> >On Nov 30 23:59, Francis ANDRE wrote:
> >>Hi
> >>
> >>The following set-x86.exe command in unattended mode crashes on Win7
> >>
> >>C:\Users\FrancisANDRE>c:\cygwin\bin\uname.exe -a
> >>CYGWIN_NT-6.1-WOW idefix 2.3.1(0.291/5/3) 2015-11-14 12:42 i686 Cygwin
> >>
> >>C:\Users\FrancisANDRE>c:\cygwin\setup-x86.exe -B -D -q -n  -d -R cygwin -s
> >>http://mirror.csclub.uwaterloo.ca/cygwin  -P unzip
> >The crash is not nice and I'm just looking into that, but the path you
> >specify with the -R option is supposed to be an absolute DOS path, e.g.
> >C:/cygwin.  Please try this, it should get you further.
> Thanks for the tips.. It avoids the crash. By the way, what is the option to
> set in order to avoid the Progress popup window?

I don't think there is one at the moment.  I wouldn't be unhappy if
somebody comes up with code to implement a --very-very-silent option :)


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpJaI_zRq5R7.pgp
Description: PGP signature

Re: [PATCH v2] Introduce the 'usertemp' filesystem type

[Johannes Schindelin]

... and here is the interdiff vs v1 (compare also to the 'pseudo Pull
Request' at
https://github.com/dscho/msys2-runtime/compare/tempfs-cygwin-v1-rebased...tempfs-cygwin-v2):

diff --git a/winsup/cygwin/include/sys/mount.h
b/winsup/cygwin/include/sys/mount.h
index 458cf80..ec92794 100644
--- a/winsup/cygwin/include/sys/mount.h
+++ b/winsup/cygwin/include/sys/mount.h
@@ -44,7 +44,8 @@ enum
   MOUNT_DOS =  0x4,/* convert leading spaces and trailing
   dots and spaces to private use area 
*/
   MOUNT_IHASH =0x8,/* Enforce hash values for 
inode numbers */
-  MOUNT_BIND = 0x10/* Allows bind syntax in fstab file. */
+  MOUNT_BIND = 0x10,   /* Allows bind syntax in fstab file. */
+  MOUNT_USER_TEMP =0x20/* Mount the user's $TMP. */
 };
 
 int mount (const char *, const char *, unsigned __flags);
diff --git a/winsup/cygwin/mount.cc b/winsup/cygwin/mount.cc
index be5de61..fc080c9 100644
--- a/winsup/cygwin/mount.cc
+++ b/winsup/cygwin/mount.cc
@@ -1200,14 +1200,15 @@ mount_info::from_fstab_line (char *line, bool user)
 }
   else if (!strcmp (fs_type, "usertemp"))
 {
-  WCHAR tmp[MAX_PATH];
+  WCHAR tmp[PATH_MAX + 1];
 
-  if (GetEnvironmentVariableW (L"TEMP", tmp, sizeof(tmp)) && *tmp)
+  if (GetTempPathW (PATH_MAX, tmp))
{
-  DWORD len;
-  char mb_tmp[len = sys_wcstombs (NULL, 0, tmp)];
-  sys_wcstombs (mb_tmp, len, tmp);
+ tmp_pathbuf tp;
+ char *mb_tmp = tp.c_get ();
+ sys_wcstombs (mb_tmp, PATH_MAX, tmp);
 
+ mount_flags |= MOUNT_USER_TEMP;
  int res = mount_table->add_item (mb_tmp, posix_path, mount_flags);
  if (res && get_errno () == EMFILE)
return false;
@@ -1670,6 +1671,9 @@ fillout_mntent (const char *native_path, const char 
*posix_path, unsigned flags)
   if (flags & (MOUNT_BIND))
 strcat (_my_tls.locals.mnt_opts, (char *) ",bind");
 
+  if (flags & (MOUNT_USER_TEMP))
+strcat (_my_tls.locals.mnt_opts, (char *) ",usertemp");
+
   ret.mnt_opts = _my_tls.locals.mnt_opts;
 
   ret.mnt_freq = 1;