[PATCH] ssh bash completion with usernames containing spaces
Hi,
unfortunately my username contains a space and thus also my home
directory. The bash completion for ssh and scp had problems with that,
as some quotations in /etc/bash_completion where missing. I fixed it and
created a patch.
As I don't know who the maintainer of this file is, I send it to you in
hope to reach the right person.
I am running cygwin 1.7.27 x86_64.
Best regards,
Quirin Funke
--- bash_completion 2013-12-03 11:08:42.038628800 +0100
+++ bash_completion_new 2013-12-03 11:11:15.160939500 +0100
@@ -1247,7 +1247,7 @@
else
for i in /etc/ssh/ssh_config "${HOME}/.ssh/config" \
"${HOME}/.ssh2/config"; do
-[ -r $i ] && config=( "${config[@]}" "$i" )
+[ -r "$i" ] && config=( "${config[@]}" "$i" )
done
fi
@@ -1275,10 +1275,10 @@
for i in /etc/ssh/ssh_known_hosts /etc/ssh/ssh_known_hosts2 \
/etc/known_hosts /etc/known_hosts2 ~/.ssh/known_hosts \
~/.ssh/known_hosts2; do
-[ -r $i ] && kh=( "${kh[@]}" $i )
+[ -r "$i" ] && kh=( "${kh[@]}" "$i" )
done
for i in /etc/ssh2/knownhosts ~/.ssh2/hostkeys; do
-[ -d $i ] && khd=( "${khd[@]}" $i/*pub )
+[ -d "$i" ] && khd=( "${khd[@]}" "$i"/*pub )
done
fi
--
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: shared object file not found with `git submodule update --init --recursive` in Cygwin 64-bit
On 6 November 2013 00:39, Tandetzky, Max wrote: > Hello Kal, > > installing the Devel\gettext package should solve your problem. git-submodule > requires that. Unfortunately this is not marked as dependency. > > Regards, > Max > > -- > 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 > Thanks Max! I missed your reply for a whole month because GMail sorted it into a separate thread somehow. Anyway, I installed the gettext package and the problem is gone now. Thank you again. Regards, Kal -- 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: cant access to files more than 128 utf-8 symbol long names
Greetings, Corinna Vinschen! >> >Sorry if that is frustrating in your current situation, but this >> >isn't something we can just change at a whim and go ahead. It >> >would break compatibility with all existing Cygwin executables. >> >> Maybe this is something that could be fixed only in the 64-bit version of >> Cygwin? > Did you really read my mail? There is no fix. You can handle this > wrongly one way or the other. If in doubt, I prefer the POSIXly correct > way. After off-list discussion, Nikolay partially solved this issue by using locale-appropriate single-byte encoding in LANG. In this case, LANG=ru_RU.CP1251 It is far from a perfect solution, but at least let him access the files in question. -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.12.2013, <13:12> 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
Install Bash 4.2 for Cygwin fails
I tried to install bash 4.2 but I get this error when I write "make" rm -f bash.exe gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/sh -L./lib/termcap-g -O2 -o bash.exe shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o bashhist.o bashline.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lglob -lsh -lreadline -lhistory ./lib/termcap/libtermcap.a -ltilde lib/intl/libintl.a-ldl general.o: En la función `make_absolute': /bash-4.2/general.c:630: referencia a `cygwin_conv_to_full_posix_path' sin definir /bash-4.2/general.c:630:(.text+0xcc9): reubicación truncada para ajustar: R_X86_64_PC32 contra el símbolo `cygwin_conv_to_full_posix_path' sin definir collect2: error: ld devolvió el estado de salida 1 Makefile:540: recipe for target 'bash.exe' failed make: *** [bash.exe] Error 1 I dont know what I need to do. Thanks! :) -- 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: cant access to files more than 128 utf-8 symbol long names
On Dec 11 11:04, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > > The problem here is about NAME_MAX. NAME_MAX is per POSIX[1] the > > "maximum number of bytes in a filename (not including the terminating > > null)." > > Does this mean that POSIX standard is not compatible with real life? Are you asking nonsensical questions for fun or did you not read my mail closely, too? I made the effort to reply to the OP with a detailed mail explaining the issue. I don't understand what this sniding reaction is supposed to accomplish. POSIX and Windows are not naturally compatible. Cygwin tries hard to bridge the gap, but sometimes the gap is really wide. But thanks anyway for providing a solution to the problem by setting the locale environment variables. That might make a good FAQ entry, *iff* somebody has the incentive to write one. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7p23tnzqvs.pgp Description: PGP signature
Re: Install Bash 4.2 for Cygwin fails
On Dec 11 11:10, Javier Murillo Márquez wrote: > I tried to install bash 4.2 but I get this error when I write "make" > > rm -f bash.exe > gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob > -L./lib/tilde -L./lib/sh -L./lib/termcap-g -O2 -o bash.exe > shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o > execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o > subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o > pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o assoc.o > braces.o bracecomp.o bashhist.o bashline.o list.o stringlib.o > locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o > -lbuiltins -lglob -lsh -lreadline -lhistory ./lib/termcap/libtermcap.a > -ltilde lib/intl/libintl.a-ldl > general.o: En la función `make_absolute': > /bash-4.2/general.c:630: referencia a `cygwin_conv_to_full_posix_path' > sin definir > /bash-4.2/general.c:630:(.text+0xcc9): reubicación truncada para > ajustar: R_X86_64_PC32 contra el símbolo > `cygwin_conv_to_full_posix_path' sin definir > collect2: error: ld devolvió el estado de salida 1 > Makefile:540: recipe for target 'bash.exe' failed > make: *** [bash.exe] Error 1 > > I dont know what I need to do. Thanks! :) Bash 4.2 is *still* using the old and long deprecated cygwin_conv_to_full_posix_path function. It should long have changed the call to use the cygwin_conv_path or cygwin_create_path function. Eric? Any chance to update bash? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqyrgTAxdva.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86)
On 12/11/2013 02:07, Corinna Vinschen wrote: > On Dec 10 18:32, Achim Gratz wrote: >> Corinna Vinschen writes: >>> Does it make sense to remove the libquadmath0gcc-ada package entirely >>> for now? >> >> Yes, the whole libquadmath0gcc-ada directory including the files in it. >> Then setup.ini should have the 4.8.2-1 package version of libquadmath as >> current until it gets replaced with the -2 or -3 version. > > Jon? That's ok with you? I just reuploaded -2 and deleted the stray libquadmath0gcc-ada. Both new and existing users should not notice any big difference other than an update. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86)
On Dec 11 19:35, JonY wrote: > On 12/11/2013 02:07, Corinna Vinschen wrote: > > On Dec 10 18:32, Achim Gratz wrote: > >> Corinna Vinschen writes: > >>> Does it make sense to remove the libquadmath0gcc-ada package entirely > >>> for now? > >> > >> Yes, the whole libquadmath0gcc-ada directory including the files in it. > >> Then setup.ini should have the 4.8.2-1 package version of libquadmath as > >> current until it gets replaced with the -2 or -3 version. > > > > Jon? That's ok with you? > > I just reuploaded -2 and deleted the stray libquadmath0gcc-ada. Both new > and existing users should not notice any big difference other than an > update. Cool, thanks! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7oSShwOCaN.pgp Description: PGP signature
Re: cant access to files more than 128 utf-8 symbol long names
On Tue, 10 Dec 2013 11:27:55 +0100 Corinna Vinschen <...> wrote: > Easier said than done. > > Cygwin is using the native NT API > and, occasionally, the Win32 UNICODE file API, which allows paths of up > to 32767 chars. > ... > How do you represent this in a byte-oriented POSIX system? What do you > set NAME_MAX to? You can't get it right due to the unfortunate multibyte > vs. UTF-16 encoding issue. > > To cover all UTF-8 chars, NAME_MAX would have to be 1020. But then, > applications relying on NAME_MAX will be surprised by ENAMETOOLONG > errors for perfectly valid POSIX filenames. > > If you make it 255, applications will be surprised by ENAMETOOLONG > errors for perfectly valid Windows filenames. > Strictly speaking, the NAME_MAX and PATH_MAX POSIX' limits must be 32767*4 bytes, that is ~128K on Windows systems. With such a value no one Cygwin application running on the Windows does not come across the ENAMETOOLONG error because of the nonexistence of the actual filenames with this length (and hence POSIX filenames too). Did I understand rigth? -- -- 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: Problems with Cygwin symlinks on a TrueCrypt volume
On Dec 6 17:33, Corinna Vinschen wrote: > On Dec 6 15:18, Dr Rainer Woitok wrote: > > Greetings, > > > > I just happened to stumble over the problem described below. > > > > Additional information: > > > > - Windows Vista, patched this week. > > > > - Cygwin updated this week. > > > > - TrueCrypt downloaded and installed this week. > > [...] > > $ cd /g > > $ ln -s . xx > > $ ls -nl xx > > lrwxrwxrwx 1 1002 513 1 2013-12-06 11:38 xx -> . > > $ rm xx* > > rm: cannot remove `xx': Permission denied > > $ rm -f xx* > > rm: cannot remove `xx': Permission denied > > $ ls -nl xx* > > lrwxrwxrwx 1 1002 513 1 2013-12-06 11:38 xx -> . > > [...] > > $ attrib -r 'g:\xx.lnk' > > $ rm xx.lnk > > $ ls -nl xx* > > ls: cannot access xx*: No such file or directory > > $ > > [...] > > I really dont't know whether Windows or TrueCrypt is incorrectly inter- > > preting the DOS ReadOnly attribute, and thus whose fault this is. I > > would simply suggest to change the code of the "rm" command so it ex- > > plicitly removes the DOS ReadOnly attribute before it unlinks any ob- > > ject. > > Cygwin's unlink function already removes the R/O attribute if it exists, > because the OS equivalent to the POSIX unlink function refuses to remove > files with the R/O attribute set. I assume there's some weirdness in the > handling of the R/O attribute in TrueCrypt, but that's just speculation. > > What you can do to help this issue along: The same as above, but run > rm under strace: > > $ strace -o rm.trace rm -f xx > > The -f flag drops the interactive prompt. I added lots of debug output > to the unlink functionality over time, so the rm.trace file should > contain a lot of interesting details as to what's going wrong here. > Just appand the rm.trace file to your next reply. Per the strace your sent via PM (NtOpenFile after RtlSetCurrentTransaction returns with STATUS_RM_NOT_ACTIVE), I created a patch which stops the transaction if the following NtOpenFile returns with a certain set of status codes and tries to call NtOpenFile again, outside of a transaction. I created a new snapshot with this patch. Please give the latest snapshot from http://cygwin.com/snapshots/ a try and report back. Apart from that, there's a chance that this is a problem not related to Cygwin's usage of a transaction on a TrueCrypt volume in the first place. Can you try the workaround from http://support.microsoft.com/kb/948252 and see if that fixes the issue with the release Cygwin DLL 1.7.27? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpecYynbGHrd.pgp Description: PGP signature
Re: cant access to files more than 128 utf-8 symbol long names
On Dec 11 17:49, Mikhail Usenko wrote: > On Tue, 10 Dec 2013 11:27:55 +0100 > Corinna Vinschen <...> wrote: > > > > Easier said than done. > > > > Cygwin is using the native NT API > > and, occasionally, the Win32 UNICODE file API, which allows paths of up > > to 32767 chars. > > ... > > How do you represent this in a byte-oriented POSIX system? What do you > > set NAME_MAX to? You can't get it right due to the unfortunate multibyte > > vs. UTF-16 encoding issue. > > > > To cover all UTF-8 chars, NAME_MAX would have to be 1020. But then, > > applications relying on NAME_MAX will be surprised by ENAMETOOLONG > > errors for perfectly valid POSIX filenames. > > > > If you make it 255, applications will be surprised by ENAMETOOLONG > > errors for perfectly valid Windows filenames. > > > > Strictly speaking, the NAME_MAX and PATH_MAX POSIX' limits must be > 32767*4 bytes, that is ~128K on Windows systems. With such a value no Strictly speaking you're wrong. NAME_MAX is the length of a single path component, not the length of a path: NAME_MAX vvv /foo/bar/baz\0 ^^ PATH_MAX Also, PATH_MAX is NOT the maximum length of a path, but the "Maximum number of bytes the implementation will store as a pathname in a user-supplied buffer of unspecified size, including the terminating null character." That does not mean there are no longer paths possible, just that you have to use, for instance, relative paths rather than absolute paths, if the absolute path becomes longer than PATH_MAX, and that the system does not guarantee to return paths if they are longer then PATH_MAX. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp9o_xta4qFS.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86)
JonY writes: > I just reuploaded -2 and deleted the stray libquadmath0gcc-ada. Both new > and existing users should not notice any big difference other than an > update. Thank you, it all works correctly now. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: cant access to files more than 128 utf-8 symbol long names
I couldn't figure out how a POSIX filename passed to a Cygwin application
running on the Windows system may become longer than NAME_MAX=1020 bytes if the
maximum filename length in NTFS is 255 UTF-16 symbols (i.e. 1020 bytes for the
biggest 4 byte UTF-8 code unit)?
What causes the ENAMETOOLONG error? In the most of POSIX functions ENAMETOOLONG
is returned if the length of a component of a pathname is longer than
{NAME_MAX} or the length of a pathname exceeds {PATH_MAX}. On NTFS there is no
files with pathname component longer than 1020 bytes and the length of the full
pathname is limited by the Unicode API (32767 chars * 4 byte = 128KiB).
--
--
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: cant access to files more than 128 utf-8 symbol long names
On Dec 11 19:02, Mikhail Usenko wrote: > I couldn't figure out how a POSIX filename passed to a Cygwin > application running on the Windows system may become longer than > NAME_MAX=1020 bytes if the maximum filename length in NTFS is 255 > UTF-16 symbols (i.e. 1020 bytes for the biggest 4 byte UTF-8 code > unit)? Read my mail again. NAME_MAX is 255. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpIhdQkyXZum.pgp Description: PGP signature
Re: cant access to files more than 128 utf-8 symbol long names
On Wed, 11 Dec 2013 16:23:39 +0100 Corinna Vinschen <...> wrote: > On Dec 11 19:02, Mikhail Usenko wrote: > > I couldn't figure out how a POSIX filename passed to a Cygwin > > application running on the Windows system may become longer than > > NAME_MAX=1020 bytes if the maximum filename length in NTFS is 255 > > UTF-16 symbols (i.e. 1020 bytes for the biggest 4 byte UTF-8 code > > unit)? > > Read my mail again. NAME_MAX is 255. > > > Corinna Corinna, why not 1020? -- -- 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: cant access to files more than 128 utf-8 symbol long names
On Dec 11 19:27, Mikhail Usenko wrote: > On Wed, 11 Dec 2013 16:23:39 +0100 > Corinna Vinschen <...> wrote: > > > On Dec 11 19:02, Mikhail Usenko wrote: > > > I couldn't figure out how a POSIX filename passed to a Cygwin > > > application running on the Windows system may become longer than > > > NAME_MAX=1020 bytes if the maximum filename length in NTFS is 255 > > > UTF-16 symbols (i.e. 1020 bytes for the biggest 4 byte UTF-8 code > > > unit)? > > > > Read my mail again. NAME_MAX is 255. > > > > > > Corinna > > Corinna, why not 1020? That's answered in my original mail. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpxaSVVyCQqa.pgp Description: PGP signature
Re: cant access to files more than 128 utf-8 symbol long names
On Wed, Dec 11, 2013 at 05:21:37PM +0100, Corinna Vinschen wrote: >On Dec 11 19:27, Mikhail Usenko wrote: >> On Wed, 11 Dec 2013 16:23:39 +0100 >> Corinna Vinschen <...> wrote: >> >> > On Dec 11 19:02, Mikhail Usenko wrote: >> > > I couldn't figure out how a POSIX filename passed to a Cygwin >> > > application running on the Windows system may become longer than >> > > NAME_MAX=1020 bytes if the maximum filename length in NTFS is 255 >> > > UTF-16 symbols (i.e. 1020 bytes for the biggest 4 byte UTF-8 code >> > > unit)? >> > >> > Read my mail again. NAME_MAX is 255. >> > >> > >> > Corinna >> >> Corinna, why not 1020? > >That's answered in my original mail. Perhaps this will require reiteration and reclarification on Thursday, feline-permitting. YMMV! cgf -- 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
Permissions Issue with Nested and/or local Groups
We have a file share on machine1. Machine1 has a local group, share_read, that contains a domain group share_readers and share_readers has a list of individuals with access to the share. From Windows access is fine. In Cygwin, ls -l is showing no access to the files for the users. Adding the domain group directly to the share solves the problem. I'm even able to duplicate this behavior locally on my machine with a group and a folder local to the machine, so it's not the fact that it's a network share. And adding my domain account directly to the local group does not work either. So it appears the culprit might be the local group. Any thoughts? Thanks In Advance, Dave -- 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: cant access to files more than 128 utf-8 symbol long names
On Dec 11 11:30, Christopher Faylor wrote: > On Wed, Dec 11, 2013 at 05:21:37PM +0100, Corinna Vinschen wrote: > >On Dec 11 19:27, Mikhail Usenko wrote: > >> On Wed, 11 Dec 2013 16:23:39 +0100 > >> Corinna Vinschen <...> wrote: > >> > >> > On Dec 11 19:02, Mikhail Usenko wrote: > >> > > I couldn't figure out how a POSIX filename passed to a Cygwin > >> > > application running on the Windows system may become longer than > >> > > NAME_MAX=1020 bytes if the maximum filename length in NTFS is 255 > >> > > UTF-16 symbols (i.e. 1020 bytes for the biggest 4 byte UTF-8 code > >> > > unit)? > >> > > >> > Read my mail again. NAME_MAX is 255. > >> > > >> > > >> > Corinna > >> > >> Corinna, why not 1020? > > > >That's answered in my original mail. > > Perhaps this will require reiteration and reclarification on Thursday, > feline-permitting. And it's not even my WJM week. Can we move that to Thursday next week? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpDWEfg9h8ef.pgp Description: PGP signature
Re: cant access to files more than 128 utf-8 symbol long names
On Wed, Dec 11, 2013 at 06:01:03PM +0100, Corinna Vinschen wrote: >>Perhaps this will require reiteration and reclarification on Thursday, >>feline-permitting. > >And it's not even my WJM week. Can we move that to Thursday next week? Sorry, no. I can't allow that. But, then, it's my week. cgf -- 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
fstab or temp mount -> HKLM mounts table?
How can I add entries to the HKLM "mounts v2" table? I tried using mount: mount f: /vol/dosf but it's only temporary, it doesn't get saved into the HKLM table. I need to update the HKLM table because the cygwin NFS server only seems to export directories that are there. E.g. if I export /vol/dosf (which is not in the HKLM table) NFS clients see an empty dir, even though on the NFS server /vol/dosf contains many things. Also, **is this documented anywhere**? The manual talks on and on about how the HKLM table gets read, but never about how to write it, which is time silly, time-consuming and annoying. Or maybe I misunderstood. Thanks. -- 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: fstab or temp mount -> HKLM mounts table?
On Wed, Dec 11, 2013 at 02:29:05PM -0500, G. Falveli wrote: >How can I add entries to the HKLM "mounts v2" table? I tried using >mount: Mounts live either in memory (transitory) or in /etc/fstab (permanent). We have not used the registry for mounts since Cygwin 1.5. -- 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: fstab or temp mount -> HKLM mounts table?
On Dec 11 14:29, G. Falveli wrote: > I need to update the HKLM table because the cygwin NFS server only > seems to export directories that are there. E.g. if I export /vol/dosf > (which is not in the HKLM table) NFS clients see an empty dir, even > though on the NFS server /vol/dosf contains many things. > > Also, **is this documented anywhere**? Did you read the User's Guide? http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html Especially: http://cygwin.com/cygwin-ug-net/using.html#mount-table > The manual talks on and on > about how the HKLM table gets read, [...] The only time the User's Guide talks "on and on" about the old registry mount points is this note at the end of the aforementioned section about the mount table: Note When you upgrade an existing older Cygwin installation to Cygwin 1.7, your old system mount points (stored in the HKEY_LOCAL_MACHINE branch of your registry) [...] > which is time silly, time-consuming and annoying. Or maybe I > misunderstood. Absolutely. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpxU0gyXPpp8.pgp Description: PGP signature
Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)
At 2013-12-10 21:40 quoth Jon TURNEY: On 04/12/2013 22:14, Markus Hoenicka wrote: Around 2013-12-04 16:59 Jon TURNEY was heard to say: On 04/12/2013 08:09, Markus Hoenicka wrote: Am 2013-12-03 22:10, schrieb Christopher Faylor: I added an ugly hack to work around this symptom in the latest cygwin. It shouldn't have any big impact on anything but this particular scenario but I would appreciate it if people downloaded today's snapshot and verified that things are still working ok. I plan on addressing the actual problem for Cygwin 1.7.28. the nightly snapshot does not seem to do me any good with regard to the clipboard problem. I performed the following test, and I hope this is what you had in mind: There is also a bug in xwinclip which needs fixing for this test to work reliably, but it was difficult to see what that was without this fix in the cygwin DLL. I see. Let me know whenever it makes sense to do any further testing. I just uploaded X server 1.14.4-2, which should have this fixed. (With cygwin DLL prior to the nightly snapshot of 2013-12-04, you may see "Spurious wake" recorded in XWin's log, but pasting should still work correctly) I'm away from my Windows box at work, but I'll make sure to test your new version when I'll be back early next week. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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
