Re: Differences in emacsclient-w32 and emacs-w32
I have a registry file which works fine. Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\*\shell\openWithEmacs] [HKEY_CLASSES_ROOT\*\shell\openWithEmacs\command] @="C:\\cygwin\\bin\\run.exe /usr/bin/bash.exe -l -c \"/usr/bin/emacsclient-w32.exe -c \\\"%1\\\" -a \\\"\\\"\"" Do notice that this only works with run version 1.29. I don't have time to fix the incompatibility with latest run 1.30. On 8/22/2013 8:10 AM, Josh Hunsaker wrote: I am having a problem opening files in emacs from Windows, and I think that the cygwin build of emacs is causing the problem. I have an "Edit" option in my windows context menu that sends files to emacs via a registry key with value: C:\cygwin\bin\emacsclient-w32.exe "%1" If I have no open instance of emacs, then it will be opened, and the file will load into a new buffer as expected. I can also repeat this action for many files, and each will load into its own buffer in the current emacs instance, as expected. By contrast, if I start emacs with emacs-w32.exe, whether from the terminal or by clicking the icon, I am unable to open files from the context menu. Instead, a new _empty_ buffer is created with a name like "F:\Users\nispio\.emacs". The value of 'buffer-file-name' for this empty buffer is "/cygdrive/f/Users/nispio/F:\\Users\\nispio\\.emacs" I cannot reproduce this problem in the standalone Windows emacs build from ftp.gnu.org. The binaries emacs.exe and emacsclientw.exe work as expected in that build. For now, I have a reasonable workaround in that I can create my first instance of emacs by opening a file from the context menu. However, after that if I want to open a file from the command-line I have to use $ emacsclient-w32 `cygpath -w ~/.emacs` or else I get a similar problem as mentioned above, but in reverse. Is there any way that I can correct this so that I can more efficiently open files in emacs from both the command line and Windows Explorer? -- 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 -- 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: shell-init: error retrieving current directory
Hi, Thanks, I see. And I noticed bash.exe of cygwin32 is also using it's own getcwd WITHOUT issue. (2013/08/22 11:21), LRN wrote: 1) It's not improperly disabled. Cygwin's getcwd does not behave the way bash wants it to (when called with 0 buffer and 0 buffer length, it fails, instead of allocating buffer). At least that is my understanding after observing the source code. 2) Also, this happens if you cross-compile bash (because this can't be autodetected when cross-compiling, and configure assumes the worst). -- 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: shell-init: error retrieving current directory
Hi, I've experienced the same issue. From what I can see: Current bash.exe of cygwin64 seems to be improperly built with HAVE_GETCWD disabled, which result in using it's own getcwd implementation in the bash source package. This can be indirectly observed by inspecting bash.exe with dependency walker or something. You can easily see that bash.exe has it's own getcwd symbol, and it's not imported from cygwin1.dll. Therefore, I downloaded bash source package from setup-x86_64.exe anyway to see what's happening, and built bash with cygport. Surprisingly, I got working bash.exe with HAVE_GETCWD enabled, without patching anything. This one, of course, imports getcwd from cygwin1.dll, and is free from the issue. So I don't know why the HAVE_GETCWD was disabled on the official build, but I think simple re-building and re-distributing of bash.exe will solve this issue. -- 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
Differences in emacsclient-w32 and emacs-w32
I am having a problem opening files in emacs from Windows, and I think that the cygwin build of emacs is causing the problem. I have an "Edit" option in my windows context menu that sends files to emacs via a registry key with value: C:\cygwin\bin\emacsclient-w32.exe "%1" If I have no open instance of emacs, then it will be opened, and the file will load into a new buffer as expected. I can also repeat this action for many files, and each will load into its own buffer in the current emacs instance, as expected. By contrast, if I start emacs with emacs-w32.exe, whether from the terminal or by clicking the icon, I am unable to open files from the context menu. Instead, a new _empty_ buffer is created with a name like "F:\Users\nispio\.emacs". The value of 'buffer-file-name' for this empty buffer is "/cygdrive/f/Users/nispio/F:\\Users\\nispio\\.emacs" I cannot reproduce this problem in the standalone Windows emacs build from ftp.gnu.org. The binaries emacs.exe and emacsclientw.exe work as expected in that build. For now, I have a reasonable workaround in that I can create my first instance of emacs by opening a file from the context menu. However, after that if I want to open a file from the command-line I have to use $ emacsclient-w32 `cygpath -w ~/.emacs` or else I get a similar problem as mentioned above, but in reverse. Is there any way that I can correct this so that I can more efficiently open files in emacs from both the command line and Windows Explorer? -- 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
setting up sshd on windows 7
I can't seem to login in with a password or with a key. /var/log/sshd.log doesn't show any errors and i dont see anything in the event viewer. i set the log level to VERBOSE in sshd_config, but nothing is shown in either. When i had incorrect permissions in /var/empty, i got errors in the event viewer and /var/log/sshd.log, so i am think logging is working, but i am not sure its reading /etc/sshd_config. I am pretty sure permissions on my home directory, .ssh and .ssh/authorized_keys are correct. One thing, my user is a domain user (not really savvy with windows login stuff), and I am pretty sure i added him to the "local login" permissions thing. any ideas? This is the output from my client $ ssh -v myhost OpenSSH_5.9p1, OpenSSL 0.9.8x 10 May 2012 debug1: Reading configuration data /Users/myuser/.ssh/config debug1: Reading configuration data /etc/ssh_config debug1: /etc/ssh_config line 20: Applying options for * debug1: /etc/ssh_config line 53: Applying options for * debug1: Connecting to myhost [10.52.54.182] port 22. debug1: Connection established. debug1: identity file /Users/myuser/.ssh/id_rsa type 1 debug1: identity file /Users/myuser/.ssh/id_rsa-cert type -1 debug1: identity file /Users/myuser/.ssh/id_dsa type -1 debug1: identity file /Users/myuser/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2 debug1: match: OpenSSH_6.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 60:77:ad:bf:4c:dc:85:2d:11:1b:c1:a2:ac:4e:09:ea debug1: Host 'myhost' is known and matches the RSA host key. debug1: Found key in /Users/myuser/.ssh/known_hosts:8 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering RSA public key: /Users/myuser/.ssh/id_rsa debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Trying private key: /Users/myuser/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: password myuser@myhost's password: -- 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: mt and tar fail on LTO-5 drives
On Aug 21 19:20, bartels wrote: > On 08/21/2013 11:51 AM, Frank Fesevur wrote: > >2013/8/20 Corinna Vinschen: > >> This bug is present since 2004 and nobody noticed it. I guess that > >> means there aren't many people out there actually partitioning their > >> tape drives... > >FYI: we use cygwin tar on a daily base to backup one server to > >LTO2-tapes, but I have never partitioned a tape. Wasn't even aware it > >could be done. > > Partitioning was first introduced on LTO with LTO-5, accommodating LTFS. Oh, right. I didn't know that, but the SCSI references for LTO drives are pretty clear. So, change the list to DDS, SLR, VXA-2, the latter of which is the only one I know which supports select partitioning. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYYMwLAJoXQ.pgp Description: PGP signature
Re: mt and tar fail on LTO-5 drives
On 08/21/2013 11:51 AM, Frank Fesevur wrote: 2013/8/20 Corinna Vinschen: This bug is present since 2004 and nobody noticed it. I guess that means there aren't many people out there actually partitioning their tape drives... FYI: we use cygwin tar on a daily base to backup one server to LTO2-tapes, but I have never partitioned a tape. Wasn't even aware it could be done. Partitioning was first introduced on LTO with LTO-5, accommodating LTFS. - Bartels -- 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: ETA for 64-bit SVN?
On 21/08/2013 12:11 PM, Corinna Vinschen wrote: On Aug 21 12:04, Ryan Johnson wrote: Hi SVN maintainer, Is a 64-bit release going to come out soon? SVN is quite a pain to build manually, compared with most other packages, especially if support for SSL, etc. is configured... Subversion is part of the 64 bit distro already before the distro has gone release... Right then... thanks for fixing that little PEBKAC... (slinks away sheepishly after realizing that he'd searched for "SVN" instead of "Subversion" all this time) Ryan -- 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: ETA for 64-bit SVN?
On Aug 21 12:04, Ryan Johnson wrote: > Hi SVN maintainer, > > Is a 64-bit release going to come out soon? SVN is quite a pain to > build manually, compared with most other packages, especially if > support for SSL, etc. is configured... Subversion is part of the 64 bit distro already before the distro has gone release... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgppEvRDcLffZ.pgp Description: PGP signature
ETA for 64-bit SVN?
Hi SVN maintainer, Is a 64-bit release going to come out soon? SVN is quite a pain to build manually, compared with most other packages, especially if support for SSL, etc. is configured... Thanks! Ryan -- 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 sshd dumping stack trace when not allocating pseudo-tty
On 8/21/2013 6:42 AM, Thorsten Glaser wrote: On Tue, 20 Aug 2013, Larry Hall (Cygwin) wrote: On 8/20/2013 4:32 AM, Thorsten Glaser wrote: On Mon, 19 Aug 2013, Larry Hall (Cygwin) wrote: and to understand the method you're using to login. SSH public-key auth, that is, RSA keys. (This is a requirement because the process will run as batch job so we cannot use any interactive auth method.) Understood but method 2 and 3 allow for this as well. They use a very different way of "getting there". One of these two methods could work for you. Hm. I must admit I’m a bit confused here, but AIUI if there’s a problem with logging in (the auth method or that the home directory is on the domain controller), then I should be unable to login with SSH key, without password, interactively, too – right? As things stands: ssh-key interactive ⇒ works password interactive ⇒ works ssh-key batch ⇒ doesn’t work (-T, running a command, scp, rsync) password batch ⇒ works There's definitely a different path being taken here and the authentication isn't "keeping up" in the failing case. Putting 'sshd' in debug mode may shed some light on why this is a problem in this particular installation. But to re-iterate my point, in case your main goal is just to find a way that works, methods 2 and 3 use different techniques to accomplish the same thing. For method 2, you have a different token, so if authenticating with a created token is causing a problem, this could help. Method 3 avoids all impersonation token issues by simply using password authentication. So this one seems like it should work based on your current testing. It's telling you that cmd.exe doesn't understand UNC paths. And that actually gives me an idea. Can you create a local home directory Hmm. When I login using ssh-key interactively, I get this: tglase@tglase:~ $ ssh cygbox Last login: Tue Aug 20 10:21:46 2013 from tglase.lan.tarent.de tglase@cygbox:~$ pwd //dc/tglase So why would it work interactively but not in batch mode? I'm saying cmd.exe is complaining, not the shell. But if you really want to understand how you get the message you're seeing in the batch case, I recommend setting up 'sshd' in debug mode, enabling verbosity on the SSH session, and turning on echoing of all scripts run by the shell. This will give you allot of output but also provide more context for the messages you see. That should help you narrow down where the complaint is coming from. and run ssh-user-config again to see if that helps? If so, you can either continue to use this configuration or try method 3. Other things I noted: 1. You're running cygwin 1.7.9. The current version is 1.7.24. You should upgrade. I cannot “just” change things like this on the system unless it’s known that not doing so fixes a problem (actually, the system isn’t even normally mine to administer, I’m just helping out). That's your choice but also it puts you into the category of an unsupported installation. Looking at it another way, how can you determine whether a newer version helps address a problem if you don't try it? 2. Your CYGWIN environment variable contains "sshd". You should remove this. I’ve got no idea where this is set; running a cygwin or CMD.EXE doesn’t set $CYGWIN or %CYGWIN%, respectively, at all. Must be part of the service settings in the registry then. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: unison2.40, unison2.45
On 2012-12-10 11:49, Andrew Schulman wrote:> The Unison packages for Cygwin have been updated: > > unison2.40, unison2.45 - new upstream minor updates. Is there any chance you could release a 64-bit build of unison? I've been using the 64-bit build of cygwin for a couple weeks now, and the only package that I regularly use that I couldn't find was unison. -- 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 installed packages list without dependencies
On 8/20/2013 8:26 PM, DynV wrote: Hello people of cygwin, Now for my main concern. I'd like to migrate from cygwin to cigwin64 but I have many packages on cygwin, the 32-bit version, that I'd need to install as well on the destination version (64-bit) before the move is made. I'm not sure which packages are still useful although most should be as I read thoroughly for a long time the first cygwin install. I'd like to review the packages then install the same (what passed the cleanup) on cygwin64. I did a search and the best I found was to use /cygcheck -c/ so I did on the origin, cygwin, which give me a bit over 450 packages (the destination of the migration being cygwin64). This is quite a list and I might as well start from scratch as I fist did (for the 32-bit version). I would very much like to know which of the 450 something were installed as dependencies so I can skip them, knowing they would be installed by installing the dependent. IIRC on aptitude, on "regular" *nix, there was a flag is a package was a dependency. So if there would be a way to reproduce such a structure and list everything that wouldn't have such flag, it would be pretty much what I'm looking for. There's no set tool for determining the dependencies for a package or list of packages, beyond "setup*.exe" that is. Dependencies for all packages are listed in the 'setup.ini' file, so you could process that to find the optimal set to install. But it may be just as easy, if not easier, for you to pick a set of packages that you know you want, install them, and then compare the list of installed packages from that round with your target. You also want to keep in mind that some of the packages you currently have installed may be obsolete now, so you wouldn't want to blindly just install everything from your current set. I'd recommend going for the directed, iterative approach. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: mksh-48b-1
On Tue, 20 Aug 2013, Chris Sutcliffe wrote: > Version 48b-1 of "mksh" has been uploaded. Cool, thanks! By the way, in case you didn’t see: thanks to the mksh/Win32 porting efforts, there is now a .ICO file in the sources which you can use – although I have no idea how to do that myself. (You can doesn’t mean you should or must, please decide that for yourself. An alternative icon is shown on the mksh webpage as SVG but only really works for the bigger pixel sizes, like 48x48, 64x64 and scalar of the modern *nix desktops.) bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- 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: mt and tar fail on LTO-5 drives
On Aug 21 11:51, Frank Fesevur wrote: > 2013/8/20 Corinna Vinschen: > > This bug is present since 2004 and nobody noticed it. I guess that > > means there aren't many people out there actually partitioning their > > tape drives... > > FYI: we use cygwin tar on a daily base to backup one server to > LTO2-tapes, but I have never partitioned a tape. Wasn't even aware it > could be done. Thanks for your info. The other alternative would have been that nobody uses Cygwin with tapes at all, which would have been kind of frustrating... :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpiOY0dHeMyM.pgp Description: PGP signature
Re: Python 2.7.5 on Cygwin64: requests installation fails
I have the same issue, it seams like python is core dumping both on python 2.7 and python 3. I sent a mail about this a couple of days a go with some more details. There is no debug package for python 3.0 so the stacktrace is somewhat limited. /R 2013/8/20 Public Joe : > Hi there! > I recently posted this issue on stackoverflow as well: on win-7 64-bit > operating system, fresh cygwin-64 installation with the default 2.7.5 > python library pip/easy install fails to install the "requests" > package. > > $ pip install requests > Downloading/unpacking requests > Downloading requests-1.2.3.tar.gz (348kB): 348kB downloaded > Running setup.py egg_info for package requests > Cleaning up... > No files/directories in /tmp/pip_build_joepublic/requests/pip-egg-info > (from PKG-INFO) > Storing complete log in /home/joepublic/.pip/pip.log > > > For more information and context: > http://stackoverflow.com/questions/18322718/python-2-7-5-on-cygwin64-requests-installation-fails > Any help would be greatly appretiated. > > Thank you very much, > Joe, the public > > -- > 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 > -- __ Robert Marklund Mobile: +46 (0)70 213 22 76 E-mail: robbelibob...@gmail.com Chat: robbelibob...@gmail.com __ -- 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 sshd dumping stack trace when not allocating pseudo-tty
On Tue, 20 Aug 2013, Larry Hall (Cygwin) wrote: > On 8/20/2013 4:32 AM, Thorsten Glaser wrote: > > On Mon, 19 Aug 2013, Larry Hall (Cygwin) wrote: > > > > > and to understand the method you're using to login. > > > > SSH public-key auth, that is, RSA keys. (This is a requirement > > because the process will run as batch job so we cannot use any > > interactive auth method.) > > Understood but method 2 and 3 allow for this as well. They use a > very different way of "getting there". One of these two methods > could work for you. Hm. I must admit I’m a bit confused here, but AIUI if there’s a problem with logging in (the auth method or that the home directory is on the domain controller), then I should be unable to login with SSH key, without password, interactively, too – right? As things stands: ssh-key interactive ⇒ works password interactive ⇒ works ssh-key batch ⇒ doesn’t work (-T, running a command, scp, rsync) password batch ⇒ works > It's telling you that cmd.exe doesn't understand UNC paths. And that > actually gives me an idea. Can you create a local home directory Hmm. When I login using ssh-key interactively, I get this: tglase@tglase:~ $ ssh cygbox Last login: Tue Aug 20 10:21:46 2013 from tglase.lan.tarent.de tglase@cygbox:~$ pwd //dc/tglase So why would it work interactively but not in batch mode? > and run ssh-user-config again to see if that helps? If so, you can > either continue to use this configuration or try method 3. > > Other things I noted: > > 1. You're running cygwin 1.7.9. The current version is 1.7.24. You > should upgrade. I cannot “just” change things like this on the system unless it’s known that not doing so fixes a problem (actually, the system isn’t even normally mine to administer, I’m just helping out). > 2. Your CYGWIN environment variable contains "sshd". You should > remove this. I’ve got no idea where this is set; running a cygwin or CMD.EXE doesn’t set $CYGWIN or %CYGWIN%, respectively, at all. > 3. You have an orphaned installation at the level of your C drive. > If you have not already, you should remove this installation. No, there’s precisely one Cygwin installation on that system, which lives in C:\CYGWIN – I checked (even looked for stray cygwin1.dll in e.g. windows\system32). Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- 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: mt and tar fail on LTO-5 drives
2013/8/20 Corinna Vinschen: > This bug is present since 2004 and nobody noticed it. I guess that > means there aren't many people out there actually partitioning their > tape drives... FYI: we use cygwin tar on a daily base to backup one server to LTO2-tapes, but I have never partitioned a tape. Wasn't even aware it could be done. Regards, Frank -- 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: How do I upgrade Postgres database in Cygwin?
Il 8/20/2013 7:27 PM, Chloe ha scritto: I updated some Cygwin packages and now I can't start Postgres: $ /usr/sbin/postmaster FATAL: database files are incompatible with server DETAIL: The data directory was initialized by PostgreSQL version 8.2, which is not compatible with this version 9.2.4. I tried [pg_upgrade](http://www.postgresql.org/docs/9.2/static/pgupgrade.html) but you need to specify both the old and new binary. Plus, pg_upgrade says it only works with 8.3. I thought I could use setup-x86.exe to pick the previous version, which is 8.2.11-1, however when I install that, then I can't start Postgres: $ /usr/sbin/postgres.exe Bad system call (core dumped) you need cygserver running as service -- 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
