Re: Cygwin DLLs being modified somehow?
Greetings, Michael DePaulo! > I am seeing very weird behavior and I am hoping that someone can explain it. > This happens on 2 different machines. My personal Windows 10 64-bit > machine, and a Windows 7 64-bit VM hosted by the X2Go project on > another continent. > It seems to be happening to multiple DLLs, but I will list one example below. > I install 32-bit Cygwin with the 2.870 installer > libopenssl100 is one of the packages that gets installed. It is at > version. 1.0.1k-1 > /bin/cygcrypto-1.0.0.dll always appears to be 1,820,199 bytes, and it > always appears to be last modified on 1/8/2015 20:30 UTC. > When I extract it from the tarball: > Its md5sum is: > c79b900428d91e5882c24bbb6bc36969 > And its sha256sum is: > 53376a3d69be996cb71abda41b7cc6bea7a599b027fe819323fafc3c433b7767 > Yet on both systems, once installed, its m5sum and sha1sum differ! > On my personal machine > 8b6881e6aab4b8438a6db784003a39fb > 0a4db441c5faff305b28bcddbaeae91d824ed7b39146a55f423d970d362fe6df > On the X2Go project machine: > 3ebfce45e66f227bc8f753ad1ef314a7 > 9305561f1417f2121ae2f05fd64ca9405814f757ab1eee8a4746963520e1724f > I do not know assembly. Another X2Go Developer, Mihai Moldovan (CC'd) > and I took a brief look at the disassembled output from objdump. It > looks like the addresses differ. It's called rebase. -- WBR, Andrey Repin (anrdae...@yandex.ru) 23.02.2015, <06:10> 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: Cygwin DLLs being modified somehow?
On 2/22/2015 7:53 PM, Michael DePaulo wrote: > I am seeing very weird behavior and I am hoping that someone can explain it. > > This happens on 2 different machines. My personal Windows 10 64-bit > machine, and a Windows 7 64-bit VM hosted by the X2Go project on > another continent. > > It seems to be happening to multiple DLLs, but I will list one example below. > > I install 32-bit Cygwin with the 2.870 installer > > libopenssl100 is one of the packages that gets installed. It is at > version. 1.0.1k-1 > > /bin/cygcrypto-1.0.0.dll always appears to be 1,820,199 bytes, and it > always appears to be last modified on 1/8/2015 20:30 UTC. > > When I extract it from the tarball: > Its md5sum is: > c79b900428d91e5882c24bbb6bc36969 > And its sha256sum is: > 53376a3d69be996cb71abda41b7cc6bea7a599b027fe819323fafc3c433b7767 > > Yet on both systems, once installed, its m5sum and sha1sum differ! [snip] The installation, you may have noticed, always runs rebase at the end. There's very little documentation left about rebase, the only one I found is in: /usr/share/doc/Cygwin/_autorebase.README -- René Berber -- 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
Cygwin DLLs being modified somehow?
I am seeing very weird behavior and I am hoping that someone can explain it. This happens on 2 different machines. My personal Windows 10 64-bit machine, and a Windows 7 64-bit VM hosted by the X2Go project on another continent. It seems to be happening to multiple DLLs, but I will list one example below. I install 32-bit Cygwin with the 2.870 installer libopenssl100 is one of the packages that gets installed. It is at version. 1.0.1k-1 /bin/cygcrypto-1.0.0.dll always appears to be 1,820,199 bytes, and it always appears to be last modified on 1/8/2015 20:30 UTC. When I extract it from the tarball: Its md5sum is: c79b900428d91e5882c24bbb6bc36969 And its sha256sum is: 53376a3d69be996cb71abda41b7cc6bea7a599b027fe819323fafc3c433b7767 Yet on both systems, once installed, its m5sum and sha1sum differ! On my personal machine 8b6881e6aab4b8438a6db784003a39fb 0a4db441c5faff305b28bcddbaeae91d824ed7b39146a55f423d970d362fe6df On the X2Go project machine: 3ebfce45e66f227bc8f753ad1ef314a7 9305561f1417f2121ae2f05fd64ca9405814f757ab1eee8a4746963520e1724f I do not know assembly. Another X2Go Developer, Mihai Moldovan (CC'd) and I took a brief look at the disassembled output from objdump. It looks like the addresses differ. -Mike -- 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: wish: setup.exe should remember the desktop icon setting
> Am 22.02.2015 um 21:53 schrieb Andrew Schulman: > >> Hi, > >> > >> when I run setup.exe for the first time, it shows a checkbox somewhere > >> at the end of the wizard, allowing me to create a Cygwin icon on the > >> desktop. > >> > >> I dont want this icon, so I uncheck that box. But when I later run > >> setup.exe again, the checkbox is checked again, and I have to manually > >> uncheck it again. > >> > >> setup.exe should remember the last setting of the checkbox. > > > > Running setup with the -n switch, > > > > setup-x86_64.exe -n > > > > disables creation of the shortcuts. > > I dont think Im the only one who doesnt like the current behavior. > Therefore it should be fixed directly in setup.exe. It alread remembers > the preferred download site, so why not extend this to also remembering > the users desktop icon preference? > > And whenever a user changes his mind, he will see the checkbox again > after every installation of a package. (Since thats how setup.exe > currently works.) OK, but I feel sure the answer to these suggestions will be: PTC. (https://cygwin.com/acronyms/) -- 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: wish: setup.exe should remember the desktop icon setting
Am 22.02.2015 um 21:53 schrieb Andrew Schulman: >> Hi, >> >> when I run setup.exe for the first time, it shows a checkbox somewhere >> at the end of the wizard, allowing me to create a Cygwin icon on the >> desktop. >> >> I don’t want this icon, so I uncheck that box. But when I later run >> setup.exe again, the checkbox is checked again, and I have to manually >> uncheck it again. >> >> setup.exe should remember the last setting of the checkbox. > > Running setup with the -n switch, > > setup-x86_64.exe -n > > disables creation of the shortcuts. I don’t think I’m the only one who doesn’t like the current behavior. Therefore it should be fixed directly in setup.exe. It alread remembers the preferred download site, so why not extend this to also remembering the user’s desktop icon preference? And whenever a user changes his mind, he will see the checkbox again after every installation of a package. (Since that’s how setup.exe currently works.) Roland -- 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: no info in the texinfo-package
Am 22.02.2015, 20:26 Uhr, schrieb Ken Brown: $ grep '@ info' http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f/x86/setup.ini @ info There it is. Setup says 5.2-3: "Keep" for info, I now did re-install it, no clue why it was gone. Had to run update-info-dir.sh.done to get dir, and it seems ok now. Are you installing Cygwin by some method other than setup.exe? The info Most of the time I use setup, sometimes I install things manually (quick and dirty tar -x...), some I build myself. Thanks, -Helmut -- -- 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
Unexpected EINVAL from pthread_join
It seems that a signal can cause pthread_join to incorrectly return EINVAL. I debugged it only a little but hopefully someone finds this useful: In the file thread.cc, function pthread::join, the call to cygwait may return WAIT_SIGNALED if a signal is sent to the process. The switch statement handling the return value assumes that only WAIT_OBJECT_0 and WAIT_CANCELED are possible. The default section of the switch statement has a comment "should never happen" and it returns EINVAL. It might be that the problem occurs only when SA_RESTART isn't used. -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode -- 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: wish: setup.exe should remember the desktop icon setting
> Hi, > > when I run setup.exe for the first time, it shows a checkbox somewhere > at the end of the wizard, allowing me to create a Cygwin icon on the > desktop. > > I dont want this icon, so I uncheck that box. But when I later run > setup.exe again, the checkbox is checked again, and I have to manually > uncheck it again. > > setup.exe should remember the last setting of the checkbox. Running setup with the -n switch, setup-x86_64.exe -n disables creation of the shortcuts. You can easily add the -n switch to a desktop shortcut that you use to run setup, so you don't get bothered by this again. Run setup-x86_6.exe --help to see a list of all of the supported command-line switches. Andrew -- 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: wish: setup.exe should remember the desktop icon setting
Roland Illig gmx.de> writes: > > Hi, > > when I run setup.exe for the first time, it shows a checkbox somewhere > at the end of the wizard, allowing me to create a Cygwin icon on the > desktop. > > I don’t want this icon, so I uncheck that box. But when I later run > setup.exe again, the checkbox is checked again, and I have to manually > uncheck it again. > > setup.exe should remember the last setting of the checkbox. > > Roland Check the options: /cygdrive/c/cygwin/setup-x86.exe --help Make shortcut, e.g. via File Explore, to setup-x86.exe R-CLK on the shortcut and click on Properties In the Shortcut tab, in the Target slot, add --no-desktop , e.g., C:\cygwin\setup-x86.exe --no-desktop Can do the same for /cygdrive/c/cygwin64/setup-x86_64.exe Lester
Re: no info in the texinfo-package
On 2/22/2015 2:26 PM, Helmut Karlowski wrote: Am 22.02.2015, 19:07 Uhr, schrieb Ken Brown: On 2/22/2015 1:30 PM, Helmut Karlowski wrote: Hello there's no info-program in the texinfo-package. I re-installed texinfo and it was still not there. See https://sourceware.org/ml/cygwin-announce/2014-11/msg2.html . I've been looking for an info-package, but found none: e.g.: ftp://ftp-stud.hs-esslingen.de/pub/Mirrors/sources.redhat.com/cygwin/x86/release/ It should be in x86/release/texinfo. Of course also none in the setup-ini-file. $ grep '@ info' http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f/x86/setup.ini @ info Are you installing Cygwin by some method other than setup.exe? The info package is in the Base category and should be in every Cygwin install. Or maybe your mirror is out of date. Ken -- 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: Clearing O_NONBLOCK from a pipe may lose data
(I have now subscribed to the list to get everyone's replies. Sorry for breaking the message thread.) Eric Blake wrote: > On 02/20/2015 01:21 PM, Lasse Collin wrote: > > The above Cygwin behavior would make it very easy to add a > > workaround to xz for the pipe-data-loss problem: simply don't clear > > O_NONBLOCK on stdout. However, I wonder if it is a bug in Cygwin > > that the changes to file status flags aren't seen via other file > > descriptors that refer to the same file description. If it is a > > bug, then the workaround idea will cause trouble in the future when > > the bug in Cygwin gets fixed. > > Yeah, the fact that cygwin is buggy with respect to POSIX may break > any workaround you add if cygwin is later patched. OK. I think I will keep stdout in blocking mode in xz on Cygwin for now. The race condition in signal handling is a very minor issue compared to data loss. Thomas Wolff wrote: > I see no strict requirement that the fcntl call removing O_NONBLOCK > from a file descriptor should itself still be handled as nonblocking > (it can well be argued that the flag is changed first and then the > call is allowed to block) - and even if this were not proper it is > certainly more acceptable than losing data. I agree that it's better than losing data even though it has some problems. Blocking F_SETFL can cause a deadlock since it is valid to do this from a single thread: 1. Create a pipe in non-blocking mode. 2. Write up to PIPE_BUF bytes to the pipe. 3. Set pipe to blocking mode. 4. Read from the pipe. I don't know why a program would do that, so maybe it's not a problem in practice. Even if it is a problem, a deadlock should be easier to debug than silent data loss. What should be done if the thread blocked in F_SETFL receives a signal? Usually blocking syscalls can be interrupted by signals if SA_RESTART isn't used. Looking at POSIX and Linux fcntl() man pages, the possibility of EINTR is mentioned for specific commands and F_SETFL isn't among them. It sounds likely that applications aren't prepared to restart F_SETFL (at least xz isn't), and using EINTR would lead to data loss, although it would no longer be silent data loss since it can be detected from fcntl's return value. It's worth noting that the interrupting signal doesn't necessarily come from a user; it may be e.g. SIGALRM that was requested via alarm(). On the other hand, if the fcntl() call is restarted after a signal even when SA_RESTART isn't used, a program may become unresponsive to signals. Even then this sounds less bad than unexpected EINTR (assuming that applications aren't prepared to restart F_SETFL). Alternative idea: Would there be a significant downside if Cygwin remembered if non-blocking mode was enabled at some point and close() would use that flag instead of the current (non)blocking status to determine if the background thread hack should be used? -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode -- 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: no info in the texinfo-package
Am 22.02.2015, 19:07 Uhr, schrieb Ken Brown: On 2/22/2015 1:30 PM, Helmut Karlowski wrote: Hello there's no info-program in the texinfo-package. I re-installed texinfo and it was still not there. See https://sourceware.org/ml/cygwin-announce/2014-11/msg2.html . I've been looking for an info-package, but found none: e.g.: ftp://ftp-stud.hs-esslingen.de/pub/Mirrors/sources.redhat.com/cygwin/x86/release/ ... imlib2 Verzeichnis 11.02.2015 04:35:00 indent Verzeichnis 05.02.2015 17:35:00 inetutils Verzeichnis 05.02.2015 17:38:00 initscripts Verzeichnis 05.02.2015 17:39:00 input-pad Verzeic ... Of course also none in the setup-ini-file. In checked out the texinfo-source, built it and found that the info-program is called ginfo, maybe that's why it's missing? Also I have no dir (the default top-node) in /usr/share/info though it certainly was there before. Try running /etc/postinstall/update-info-dir.sh[.done]. No effect: 673/etc/postinstall$dash -x update-info-dir.sh.done + rm -f /usr/info/dir.info /usr/share/info/dir.info /usr/info/dir /usr/share/info/dir 674/etc/postinstall$ll /usr/share/info/dir* ls: cannot access /usr/share/info/dir*: No such file or directory 675/etc/postinstall$ll /usr/info/dir* ls: cannot access /usr/info/dir*: No such file or directory -Helmut -- -- 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: no info in the texinfo-package
On 2/22/2015 1:30 PM, Helmut Karlowski wrote: Hello there's no info-program in the texinfo-package. I re-installed texinfo and it was still not there. See https://sourceware.org/ml/cygwin-announce/2014-11/msg2.html . In checked out the texinfo-source, built it and found that the info-program is called ginfo, maybe that's why it's missing? Also I have no dir (the default top-node) in /usr/share/info though it certainly was there before. Try running /etc/postinstall/update-info-dir.sh[.done]. Ken -- 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
no info in the texinfo-package
Hello there's no info-program in the texinfo-package. I re-installed texinfo and it was still not there. In checked out the texinfo-source, built it and found that the info-program is called ginfo, maybe that's why it's missing? Also I have no dir (the default top-node) in /usr/share/info though it certainly was there before. -Helmut -- -- 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
wish: setup.exe should remember the desktop icon setting
Hi, when I run setup.exe for the first time, it shows a checkbox somewhere at the end of the wizard, allowing me to create a Cygwin icon on the desktop. I don’t want this icon, so I uncheck that box. But when I later run setup.exe again, the checkbox is checked again, and I have to manually uncheck it again. setup.exe should remember the last setting of the checkbox. Roland -- 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: bug: setup.exe repeatedly warns about space in folder name
Am 22.02.2015 um 17:26 schrieb Andrey Repin: > Greetings, Roland Illig! > >> I have installed cygwin into C:\Program Files\cygwin. When I installed >> it for the first time, setup.exe warned me that there might be problems >> doing this. This warning was ok. > >> But now, when I run setup.exe again, it warns me again, although I have >> already installed cygwin and just want to install some new packages. > >> This warning is annoying and should only be displayed when the >> destination folder doesn’t exist yet. > > This warning is there to (surprize!) warn you that this configuration is > unsafe and unsupported. I know, but I don’t need this warning every time I install a new package. Roland -- 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
wish: when setup.exe detects a running Cygwin process, it should retry
Hi, when setup.exe is updating some packages and detects that there are running Cygwin processes, it shows a dialog listing the running processes. At the bottom of the dialog there are two buttons: Abort and Continue. As long as it is shown, the dialog should regularly check the running processes, and when all these processes are gone, close itself automatically, so that no further interaction is needed. If that is not possible, there should be a Recheck button at the bottom of the dialog to re-do the check for running processes. Another closely related issue: it seems to me that there is a running_processes_found flag somewhere that is set to true when this dialog pops up. This seems wrong since it should only be set when there were some running processes _and_ the user has chosen to continue anyway. Roland -- 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: [ANNOUNCEMENT] Updated: units-2.11-1
On Sun, 2015-02-22 at 15:28 +, Sam Edge wrote: > On 20/02/2015 22:12, Yaakov Selkowitz wrote: > > The following package has been updated in the Cygwin distribution: > > > > * units-2.11-1 > > > > Thanks for the update but why the dependencies on Python 3 stuff? Seems > to work fine without them. (Apologies if I'm repeating something - it's > been a while since I was on here.) The currency database updater script (units_cur) is written in Python. -- Yaakov -- 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
[ANNOUNCEMENT] New: svm-3.20-1
The following packages have been added to the Cygwin distribution: * svm-3.20-1 * libsvm2-3.20-1 * libsvm-devel-3.20-1 LIBSVM is an integrated software for support vector classification, (C-SVC, nu-SVC), regression (epsilon-SVR, nu-SVR), and distribution estimation (one-class SVM). It supports multi-class classification. libsvm2 is being added to the distribution as a dependency of the next release of clisp. Ken Brown Cygwin's svm maintainer -- 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: bug: setup.exe repeatedly warns about space in folder name
Greetings, Roland Illig! > I have installed cygwin into C:\Program Files\cygwin. When I installed > it for the first time, setup.exe warned me that there might be problems > doing this. This warning was ok. > But now, when I run setup.exe again, it warns me again, although I have > already installed cygwin and just want to install some new packages. > This warning is annoying and should only be displayed when the > destination folder doesn’t exist yet. This warning is there to (surprize!) warn you that this configuration is unsafe and unsupported. -- WBR, Andrey Repin (anrdae...@yandex.ru) 22.02.2015, <19:25> Sorry for my terrible english...
bug: setup.exe repeatedly warns about space in folder name
Hi, I have installed cygwin into C:\Program Files\cygwin. When I installed it for the first time, setup.exe warned me that there might be problems doing this. This warning was ok. But now, when I run setup.exe again, it warns me again, although I have already installed cygwin and just want to install some new packages. This warning is annoying and should only be displayed when the destination folder doesn’t exist yet. Roland -- 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: [ANNOUNCEMENT] Updated: units-2.11-1
On 20/02/2015 22:12, Yaakov Selkowitz wrote: > The following package has been updated in the Cygwin distribution: > > * units-2.11-1 > Thanks for the update but why the dependencies on Python 3 stuff? Seems to work fine without them. (Apologies if I'm repeating something - it's been a while since I was on here.) -- Sam Edge -- 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
[ANNOUNCEMENT] Updated: krb5-1.13.1-1
The following packages have been updated in the Cygwin distribution: * krb5-server-1.13.1-1 * krb5-server-ldap-1.13.1-1 * krb5-workstation-1.13.1-1 * krb5-pkinit-1.13.1-1 * krb5-k5tls-1.13.1-1 * krb5-samples-1.13.1-1 * krb5-doc-1.13.1-1 * libgssapi_krb5_2-1.13.1-1 * libgssrpc4-1.13.1-1 * libk5crypto3-1.13.1-1 * libkadm5clnt_mit9-1.13.1-1 * libkadm5srv_mit9-1.13.1-1 * libkdb5_8-1.13.1-1 * libkrad0-1.13.1-1 * libkrb5_3-1.13.1-1 * libkrb5support0-1.13.1-1 * libkrb5-devel-1.13.1-1 This is the reference implementation of the Kerberos network authentication protocol from MIT. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. This is an update to the latest upstream release. The sample clients and servers, and the modules for LDAP, PKINIT, and the new HTTPS transport support have all been split into separate subpackages. -- Yaakov -- 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: emacs server problem
On 2/22/2015 8:33 AM, gjnospam2014-cygwinprobl...@yahoo.com wrote: And why, suddenly, this problem related to permissions on the Local/Temp dir? The problem only surfaced after I upgraded, remember. Does this help explain it? https://cygwin.com/faq/faq.html#faq.using.ssh-pubkey-stops-working Ken -- 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: emacs server problem
Ken Brown wrote: > > It definitely seems to be something to do with permissions. In a > > standalone emacs I tried 'server-start' and got told that "The directory > > `/cygdrive/c/Users/GJ/AppData/Local/Temp/emacs197609' is unsafe" > > Do you have TEMP or TMP or TMPDIR or something like that set in your > environment to /cygdrive/c/Users/GJ/AppData/Local/Temp? If so, change > it to /tmp. (/etc/profile should do this unless you're not using the > default /etc/profile.) Yes, it is set. If I make it use /tmp then it all works. Why the difference between using /tmp and ~/.emacs.d/server ? And why, suddenly, this problem related to permissions on the Local/Temp dir? The problem only surfaced after I upgraded, remember. Anyway, many thanks, it's much appreciated. -- 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: emacs server problem (was: Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.34-6)
On 2/22/2015 5:28 AM, gjnospam2014-cygwinprobl...@yahoo.com wrote: Ken Brown wrote: Reverting to cygwin-1.7.33 "fixes" it. Ken, can you take a look, perhaps? I'm just not familiar enough with emacs... I can't reproduce it either. I think we need more details from the OP, including detailed step-by-step instructions, as well as attached cygcheck output (http://cygwin.com/problems.html). It might also be useful to see the ACL on the directory /tmp/emacs that the emacs server uses for its socket. OP, can we see the results of 'ls -l' and 'getfacl' on that directory? You might also try deleting that directory and letting emacs create a new one the next time it starts a server. It definitely seems to be something to do with permissions. In a standalone emacs I tried 'server-start' and got told that "The directory `/cygdrive/c/Users/GJ/AppData/Local/Temp/emacs197609' is unsafe" Do you have TEMP or TMP or TMPDIR or something like that set in your environment to /cygdrive/c/Users/GJ/AppData/Local/Temp? If so, change it to /tmp. (/etc/profile should do this unless you're not using the default /etc/profile.) Ken -- 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
emacs server problem (was: Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.34-6)
Ken Brown wrote: > > > Reverting to cygwin-1.7.33 "fixes" it. > > > > Ken, can you take a look, perhaps? I'm just not familiar enough with > > emacs... > > I can't reproduce it either. I think we need more details from the OP, > including detailed step-by-step instructions, as well as attached > cygcheck output (http://cygwin.com/problems.html). It might also be > useful to see the ACL on the directory /tmp/emacs that the emacs > server uses for its socket. OP, can we see the results of 'ls -l' and > 'getfacl' on that directory? You might also try deleting that > directory and letting emacs create a new one the next time it starts a > server. It definitely seems to be something to do with permissions. In a standalone emacs I tried 'server-start' and got told that "The directory `/cygdrive/c/Users/GJ/AppData/Local/Temp/emacs197609' is unsafe" $ ls -ld emacs197609/ drwxrwx---+ 1 GJ None 0 Feb 22 01:39 emacs197609// $ getfacl emacs197609/ # file: emacs197609/ # owner: GJ # group: None user::rwx user:gdj:rwx group::--- group:SYSTEM:rwx group:Administrators:rwx mask:rwx other:--- default:user::rwx default:user:gdj:rwx default:group::--- default:group:SYSTEM:rwx default:group:Administrators:rwx default:mask:rwx default:other:--- I tried setting the server-socket-dir variable to another, more private, directory, but that didn't work (in a different way). If I set the variable to, say, ~/.emacs.d/server emacs does not give me an error message when trying to start the server, but... $ /usr/bin/emacsclient -t --alternate-editor="" emacsclient: can't find socket; have you started the server? To start the server in Emacs, type "M-x server-start". [...] Starting Emacs daemon. Unable to start the daemon. Another instance of Emacs is running the server, either as daemon or interactively. You can use emacsclient to connect to that Emacs process. [...] Error: server did not start correctly Error: Could not start the Emacs daemon Running on Windows 7, non-admin account. -- 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
