Re: STC for fork SEGV after dlclose
On May 28 22:14, David Rothenberger wrote: > On 5/27/2013 12:38 PM, Corinna Vinschen wrote: > > Other than that, I'll upload a new 32 bit snapshot and a new 64 bit > > Cygwin package within the next hour or so. Please give both of them > > a try. > > The libapr1 test suite passes for both 32 bit and 64 bit with the fixes. > Thanks! Cool! Thanks for testing! Also, did you check that fork now works as expected in the dlopen/dlclose case on both platforms? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: Using native symlinks
On May 28 22:23, Chris Sutcliffe wrote: > On 28 May 2013 14:55, Corinna Vinschen wrote: > > On May 28 14:16, Chris Sutcliffe wrote: > >> What permissions do I need for native symlinks to work? According to > >> edit rights I have SeCreateSymbolicLinkPrivilege (when checking via an > >> elevated shell - i.e. with "Run as Administrator"): > >> > >> ┌─┤ csutclif@bmotec3017201lt ├──┤ ~ │ > >> └─┤ 14:11 ├─>> editrights -u $USER -l > >> SeLockMemoryPrivilege > >> SeCreateSymbolicLinkPrivilege > >> > >> However, if I try and create a native symlink it still fails. If > >> using the winsymlink:native option I get a "cygwin" symlink, winln > > > > That's "winsymlinks:native" I hope... > > Correct, I mistyped. > > >> pops up a message stating I need the SeCreateSymbolicLinkPrivilege. > >> Not sure if it's relevant or not, but the $USER in this case is a > >> domain user, not a local user. > > > > Are you sure it's an elevated shell? `id -G' should contain 544. Is > > the filesystem NTFS? Is it a local NTFS or a remote NTFS hosted by a > > Vista-or-later OS? If you set CYGWIN=winsymlink > > It works fine if I create the native symlinks in an elevated shell, > but does not if I create the native symlinks in a "normal" shell. Is > this expected (i.e. does creating native symlinks only work in > elevated shells?). Welcome to the wonderful world of native NTFS symlinks!!1!11!! It's true and it works like this: Have a look into the "Local Security Policy" MMC Snap-in. In the left hand tree view navigate to "Security Settings" -> "Local Policies" -> "User Rights Assignments". On the right side look for "Create symbolic links". You will see that by default only members of the Administrators group are allowed to create symlinks. If you're running under an admin account in a non-elevated shell, your token has been stripped by all Admin-only user rights, so you also have no right to create symlinks. To workaround that, you can either add yourself to the "Create symbolic links" right, or you can add the "Users" group if you want to allow every user to create symlinks. But this requires changing it on all machines manually, so alternatively you can create a domain policy which adds the trusted users to this user right on all machines. As if that isn't bad enough, there's another ugly surprise for the uninitiated: In an elevated shell, call fsutil like this: $ fsutil behavior query SymlinkEvaluation Local to local symbolic links are enabled. Local to remote symbolic links are enabled. Remote to local symbolic links are disabled. Remote to remote symbolic links are disabled. See the word "disabled" for remote->local and remote->remote symlinks? This means, by default the system will suppress the evaluation of remote symlinks which point to a local filesystem, as well as the evaluation of remote symlinks which point to a remote location. In CMD you'd see an error "The symbolic link cannot be followed because its type is disabled" aka STATUS_SYMLINK_CLASS_DISABLED. On Windows 8, this even goes as far as affecting NFS symlinks! If you have a symlink to a directory, with symlinks underneath, resolving the second level of symlinks fails with STATUS_NETWORK_OPEN_RESTRICTION if remote->remote symlinks are disabled in fsutil. Funny, right? The workaround is `fsutil behavior set r2l:1 r2r:1'. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: Shadowcopy volume block devices
On May 29 11:14, Micky wrote: > > That's not what you wrote in your OP. You wrote "but it doesn't let you > > access the volumes as block devices", which is pretty misleading as far > > as bug reports go. > > Sorry for not being clear enough. > > > The endless loop problem accessing the device via /proc/sys/... should > > be fixed in CVS now. > > > > Thanks for such an instant fix. > > > I created a new developer snapshot. Please give the 2012-05-28 Cygwin > > DLL from http://cygwin.com/snapshots/ a try. I also created a new 64 > > bit test release Cygwin package 1.7.19-8 with this patch included. > > I am gonna test it out soon and will report back. I'm looking forward to your feedback. Btw., as a sidenote, are you aware that you can access the filesystem underneath the volume shadow copy as well? Try this (note the trailing backslash!): $ cd /proc/sys/Device/HarddiskVolumeShadowCopy1/ $ ls The only downside is that you can't cd into the root dir of the shadowcopy by using a ".." expression: $ cd /proc/sys/Device/HarddiskVolumeShadowCopy1/Users $ cd .. /proc/sys/Device/HarddiskVolumeShadowCopy1: Not a directory. $ cd ../ /proc/sys/Device/HarddiskVolumeShadowCopy1: Not a directory. Here the path handling strips off the trailing backslash and what's left is a block device called /proc/sys/Device/HarddiskVolumeShadowCopy1. With that in mind, it's quite usable, though. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: [GOLDSTAR] Re: STC for fork SEGV after dlclose
> Andrew, I'd like to have a goldstar for David for providing short, simple, > easy to reproduce testcases in plain C. Thanks! Awarded: http://cygwin.com/goldstars/#DR -- 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 to drop administrator privileges?
Charles Wilson cwilson.fastmail.fm> writes: > On 4/27/2012 4:20 AM, Corinna Vinschen wrote: > > Fixing cygdrop. > > Thanks for the patch; I'm pretty busy this weekend but I'll try to roll > out a new cygutils release Monday or so. Sorry for this blast from the past, but cygutils have been updated a few times and I still get the same error... has the patch not been applied or is there something else that needs fixing? Regards, Achim. -- 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: Shadowcopy volume block devices
Greetings, Corinna Vinschen! > Btw., as a sidenote, are you aware that you can access the filesystem > underneath the volume shadow copy as well? > Try this (note the trailing backslash!): > $ cd /proc/sys/Device/HarddiskVolumeShadowCopy1/ > $ ls > The only downside is that you can't cd into the root dir of the > shadowcopy by using a ".." expression: > $ cd /proc/sys/Device/HarddiskVolumeShadowCopy1/Users > $ cd .. > /proc/sys/Device/HarddiskVolumeShadowCopy1: Not a directory. > $ cd ../ > /proc/sys/Device/HarddiskVolumeShadowCopy1: Not a directory. > Here the path handling strips off the trailing backslash and what's > left is a block device called /proc/sys/Device/HarddiskVolumeShadowCopy1. > With that in mind, it's quite usable, though. Can this be worked around by a symlink or junction point? (I don't have access to SVC-enabled box yet, sorry.) -- WBR, Andrey Repin (anrdae...@freemail.ru) 29.05.2013, <16:19> 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: Shadowcopy volume block devices
On May 29 16:20, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > > Btw., as a sidenote, are you aware that you can access the filesystem > > underneath the volume shadow copy as well? > > > Try this (note the trailing backslash!): > > > $ cd /proc/sys/Device/HarddiskVolumeShadowCopy1/ > > $ ls > > > The only downside is that you can't cd into the root dir of the > > shadowcopy by using a ".." expression: > > > $ cd /proc/sys/Device/HarddiskVolumeShadowCopy1/Users > > $ cd .. > > /proc/sys/Device/HarddiskVolumeShadowCopy1: Not a directory. > > $ cd ../ > > /proc/sys/Device/HarddiskVolumeShadowCopy1: Not a directory. > > > Here the path handling strips off the trailing backslash and what's > > left is a block device called /proc/sys/Device/HarddiskVolumeShadowCopy1. > > With that in mind, it's quite usable, though. > > Can this be worked around by a symlink or junction point? (I don't have access > to SVC-enabled box yet, sorry.) How do you workaround the usage of ".." with symlink or junction? If so, you don't use ".." anymore. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: {libmcrypt-doc/libmcrypt4/libmcrypt-devel}-2.5.8-11: Library for multiple encryption methods
Hi New versions of 'libmcrypt-doc/libmcrypt4/libmcrypt-devel' have been uploaded to a server near you. o Build for cygwin 1.7.18 with gcc-4.5.3 o Uses cygport for .hint files generation o debuginfo package included o Package rename: libmcrypt -> libmcrypt-doc CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: mcrypt-2.6.8-3: A replacement for the old crypt command
Hi A new version of 'mcrypt' has been uploaded to a server near you. o Build for cygwin 1.7.18 with gcc-4.5.3 o Switched to versionless .cygport file CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: Using native symlinks
On 29 May 2013 04:39, Corinna Vinschen wrote: > On May 28 22:23, Chris Sutcliffe wrote: >> It works fine if I create the native symlinks in an elevated shell, >> but does not if I create the native symlinks in a "normal" shell. Is >> this expected (i.e. does creating native symlinks only work in >> elevated shells?). > > Welcome to the wonderful world of native NTFS symlinks!!1!11!! > > It's true and it works like this: Have a look into the "Local Security > Policy" MMC Snap-in. In the left hand tree view navigate to > "Security Settings" -> "Local Policies" -> "User Rights Assignments". > On the right side look for "Create symbolic links". You will see that > by default only members of the Administrators group are allowed to > create symlinks. > > If you're running under an admin account in a non-elevated shell, your > token has been stripped by all Admin-only user rights, so you also have > no right to create symlinks. > > To workaround that, you can either add yourself to the "Create symbolic > links" right, or you can add the "Users" group if you want to allow > every user to create symlinks. But this requires changing it on all > machines manually, so alternatively you can create a domain policy which > adds the trusted users to this user right on all machines. I tried this approach and I'm still not having any luck with the user being able to create native symbolic links in a non-elevated shell. As a work around I've created a 'sudo' alias: alias sudo='cygstart --action=runas' which works nicely as I can launch commands elevated from a non-elevated shell. For running commands like winln / ln I can add the "--hidden" option (i.e. sudo --hidden) and no cmd window will pop-up during the execution of the command. I figured I would pass this along in case someone else finds this useful. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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: Using native symlinks
On May 29 10:33, Chris Sutcliffe wrote: > On 29 May 2013 04:39, Corinna Vinschen wrote: > > On May 28 22:23, Chris Sutcliffe wrote: > >> It works fine if I create the native symlinks in an elevated shell, > >> but does not if I create the native symlinks in a "normal" shell. Is > >> this expected (i.e. does creating native symlinks only work in > >> elevated shells?). > > > > Welcome to the wonderful world of native NTFS symlinks!!1!11!! > > > > It's true and it works like this: Have a look into the "Local Security > > Policy" MMC Snap-in. In the left hand tree view navigate to > > "Security Settings" -> "Local Policies" -> "User Rights Assignments". > > On the right side look for "Create symbolic links". You will see that > > by default only members of the Administrators group are allowed to > > create symlinks. > > > > If you're running under an admin account in a non-elevated shell, your > > token has been stripped by all Admin-only user rights, so you also have > > no right to create symlinks. > > > > To workaround that, you can either add yourself to the "Create symbolic > > links" right, or you can add the "Users" group if you want to allow > > every user to create symlinks. But this requires changing it on all > > machines manually, so alternatively you can create a domain policy which > > adds the trusted users to this user right on all machines. > > I tried this approach and I'm still not having any luck with the user > being able to create native symbolic links in a non-elevated shell. What approach? Adding the Users group to the Local Security Policy or adding a domain policy? If the latter, did you call gpupdate on the client or reboot the client machine to propagate the domain policy? Also, either way, did you logoff and logon so that the "Create symbolic links" user right can be added to your user token? Note that your token remains unchanged if you didn't exit from your session. Just changing the Policy isn't enough, the OS needs achance to create a new user token for you containing the user right. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: gq-1.3.4-2: Interactive graphical LDAP browser
Hi A new version of 'gq' has been uploaded to a server near you. o Build for cygwin 1.7.18 with gcc-4.5.3 o Uses cygport for .hint files generation o debuginfo package included CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: cygutils Postinstall Script Errors With Exit Code 128
On Tue, May 28, 2013 at 2:43 Paul.Nickerson wrote: > I am attempting to install Cygwin, and am getting errors near the end of > the process. I am using version 2.774 of setup.exe on Microsoft Windows > Server 2003 R2 Datacenter x64 Edition Service Pack 2 and the default > Cygwin packages. This is an Amazon AWS EC2 instance, and I am remote > desktopping in. In the Cygwin Setup GUI, after it goes through the install > procedure, I get a window titled Postinstall script errors, with the below > output text: > > Package: base-cygwin > 000-cygwin-post-install.sh exit code 128 > Package: terminfo > terminfo.sh exit code 128 > Package: bash > bash.sh exit code 128 > Package: coreutils > coreutils.sh exit code 128 > Package: _autorebase > autorebase.bat exit code -1073741819 > Package: base-files > base-files-profile.sh exit code 2816 > base-files-mketc.sh exit code 128 > Package: cygutils > cygutils.sh exit code 127 > Package: man > man.sh exit code 128 I got the cygutils postinstall error also, caused by missing dependencies. $ cat /etc/postinstall/cygutils.sh /usr/bin/update-desktop-database /usr/bin/update-mime-database /usr/share/mime both scripts do not exist, and are no cygutils reqs. please test against it. like: test -f /usr/bin/update-desktop-database && /usr/bin/update-desktop-database test -f /usr/bin/update-mime-database && /usr/bin/update-mime-database /usr/share/mime > If I then open Cygwin Terminal using the Desktop shortcut, I get a window > titled "-sh" and a prompt that says "-sh-4.1$". The command "ls" returns > "-sh: ls: command not found", but echo works. I have tried re-running > setup.exe, removing the cygwin directory, re-downloading the setup.exe, > removing HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin from the registry, > setting "Turn on DEP for essential Windows programs and services only" and > rebooting, altering file and folder permissions, deleting the cache and > using different mirrors, and using rdesktop in CentOS vs. mstsc.exe in > Windows to remote desktop in, but none of this changes the behavior. > > I have an odd and possibly related behavior. If I open Command Prompt, run > C:\cygwin\bin\bash.exe --norc --noprofile > to get a "bash-4.1$" prompt, then in there run > if [ "foo" = "foo" ]; then echo "Expression evaluated as true."; fi > the bash prompt will exit back to command prompt, and %ERRORLEVEL% has > been set to 128. > Running that if statement in the window brought up by the Cygwin Terminal > Desktop shortcut will sometimes make the window close, but not always. I > have not explored how I might be triggering the Desktop shortcut to work > or not work. > > I have attached setup.log and setup.log.full. > > When I run cygcheck -s -v -r > cygcheck.out, it hangs and does not exit. > Checking Task Manager, I see that it's using ~45% CPU (I have 2 virtual > cores). It does write some things out to cygcheck.out, which I have > attached. When I run the command in Command Prompt without redirecting > output to a file, I get a little more information before it hangs, which I > have copied out of the command prompt and attached as > cygcheck-no-redirect.out. I do not know why it's saying I have multiple > cygwin1.dlls on my path. There is only C:\cygwin\bin\cygwin1.dll. > > Looking at cygcheck.out, I am running in a Terminal Service session, which > makes sense as I am remote desktopped in. My problem might be related to > FAQ #2.14 (http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts > ), but the DEP solution is not helping me. I tried running > "C:\cygwin\bin>peflags --tsaware=true --tsaware *" in Command Prompt, but > it did not change anything. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Postinstall Script Errors With Exit Code 128
>> Paul.Nickerson at desknetinc dot com wrote on 05/28/2013 03:43:11 PM: >> From: Paul.Nickerson at desknetinc dot com >> To: cygwin at cygwin dot com, >> Date: 05/28/2013 03:43 PM >> Subject: Postinstall Script Errors With Exit Code 128 >> >> I am attempting to install Cygwin, and am getting errors near the >> end of the process. I am using version 2.774 of setup.exe on >> Microsoft Windows Server 2003 R2 Datacenter x64 Edition Service Pack >> 2 and the default Cygwin packages. This is an Amazon AWS EC2 >> instance, and I am remote desktopping in. In the Cygwin Setup GUI, >> after it goes through the install procedure, I get a window titled >> Postinstall script errors, with the below output text: >> >> Package: base-cygwin >> 000-cygwin-post-install.sh exit code 128 >> Package: terminfo >> terminfo.sh exit code 128 >> Package: bash >> bash.sh exit code 128 >> Package: coreutils >> coreutils.sh exit code 128 >> Package: _autorebase >> autorebase.bat exit code -1073741819 >> Package: base-files >> base-files-profile.sh exit code 2816 >> base-files-mketc.sh exit code 128 >> Package: cygutils >> cygutils.sh exit code 127 >> Package: man >> man.sh exit code 128 >> >> If I then open Cygwin Terminal using the Desktop shortcut, I get a >> window titled "-sh" and a prompt that says "-sh-4.1$". The command >> "ls" returns "-sh: ls: command not found", but echo works. I have >> tried re-running setup.exe, removing the cygwin directory, re- >> downloading the setup.exe, removing HKEY_LOCAL_MACHINE\SOFTWARE >> \Wow6432Node\Cygwin from the registry, setting "Turn on DEP for >> essential Windows programs and services only" and rebooting, >> altering file and folder permissions, deleting the cache and using >> different mirrors, and using rdesktop in CentOS vs. mstsc.exe in >> Windows to remote desktop in, but none of this changes the behavior. >> >> I have an odd and possibly related behavior. If I open Command Prompt, run >> C:\cygwin\bin\bash.exe --norc --noprofile >> to get a "bash-4.1$" prompt, then in there run >> if [ "foo" = "foo" ]; then echo "Expression evaluated as true."; fi >> the bash prompt will exit back to command prompt, and %ERRORLEVEL% >> has been set to 128. >> Running that if statement in the window brought up by the Cygwin >> Terminal Desktop shortcut will sometimes make the window close, but >> not always. I have not explored how I might be triggering the >> Desktop shortcut to work or not work. >> >> I have attached setup.log and setup.log.full. >> >> When I run cygcheck -s -v -r >> cygcheck.out, it hangs and does not >> exit. Checking Task Manager, I see that it's using ~45% CPU (I have >> 2 virtual cores). It does write some things out to cygcheck.out, >> which I have attached. When I run the command in Command Prompt >> without redirecting output to a file, I get a little more >> information before it hangs, which I have copied out of the command >> prompt and attached as cygcheck-no-redirect.out. I do not know why >> it's saying I have multiple cygwin1.dlls on my path. There is only >> C:\cygwin\bin\cygwin1.dll. >> >> Looking at cygcheck.out, I am running in a Terminal Service session >> which makes sense as I am remote desktopped in. My problem might be >> related to FAQ #2.14 (http://cygwin.com/faq- >> nochunks.html#faq.setup.setup-fails-on-ts), but the DEP solution is >> not helping me. I tried running "C:\cygwin\bin>>peflags -- >> tsaware=true --tsaware *" in Command Prompt, but it did not change anything. >> [attachment "setup.log.full" deleted by Paul Nickerson/DeskNetInc] >> [attachment "cygcheck.out" deleted by Paul Nickerson/DeskNetInc] >> [attachment "setup.log" deleted by Paul Nickerson/DeskNetInc] >> [attachment "cygcheck-no-redirect.out" deleted by Paul Nickerson/DeskNetInc] > "Larry Hall (Cygwin)" > Tue, 28 May 2013 17:15:00 -0400 > Try removing GS and OpenVPN from you path and try installing again. If > that doesn't work, you might try installing "Just for Me". Sorry I'm replying to my original post. I forgot to actually subscribe to the mailing list, and didn't get your message in my inbox. I tried each of your suggestions, and they did not help it install. I also tried cygcheck again, and it did not run any better. Any other ideas? I'm at a loss right now. -- 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: Postinstall Script Errors With Exit Code 128
On 5/29/2013 12:04 PM, Paul.Nickerson wrote: I tried each of your suggestions, and they did not help it install. I also tried cygcheck again, and it did not run any better. Any other ideas? I'm at a loss right now. This list has seen the occasional question about AWS and Cygwin in the past but AFAIK, no one active on the list is using AWS with Cygwin. My best suggestion at this point is to consult the Amazon folks to get their input. The fact that cygcheck doesn't run to completion really points to an issue outside of Cygwin proper, since cygcheck is a vanilla Windows program. -- 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: Using native symlinks
On 29 May 2013 11:23, Corinna Vinschen wrote: > On May 29 10:33, Chris Sutcliffe wrote: >> On 29 May 2013 04:39, Corinna Vinschen wrote: >> > To workaround that, you can either add yourself to the "Create symbolic >> > links" right, or you can add the "Users" group if you want to allow >> > every user to create symlinks. But this requires changing it on all >> > machines manually, so alternatively you can create a domain policy which >> > adds the trusted users to this user right on all machines. >> >> I tried this approach and I'm still not having any luck with the user >> being able to create native symbolic links in a non-elevated shell. > > What approach? Adding the Users group to the Local Security Policy or > adding a domain policy? If the latter, did you call gpupdate on the > client or reboot the client machine to propagate the domain policy? I've added the specific domain user in the Local Security Policy as I am not a domain admin (only an admin on the local machine) and as such cannot propagate a domain policy change. > Also, either way, did you logoff and logon so that the "Create symbolic > links" user right can be added to your user token? Note that your token > remains unchanged if you didn't exit from your session. Just changing > the Policy isn't enough, the OS needs achance to create a new user token > for you containing the user right. I've rebooted the machine since making the change and it has had no affect. Is there something else I need to do? Thanks, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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: STC for fork SEGV after dlclose
Corinna Vinschen wrote: > On May 28 22:14, David Rothenberger wrote: >> On 5/27/2013 12:38 PM, Corinna Vinschen wrote: >>> Other than that, I'll upload a new 32 bit snapshot and a new 64 bit >>> Cygwin package within the next hour or so. Please give both of them >>> a try. >> >> The libapr1 test suite passes for both 32 bit and 64 bit with the fixes. >> Thanks! > > Cool! Thanks for testing! Also, did you check that fork now works > as expected in the dlopen/dlclose case on both platforms? I hadn't (I figured you probably did) but I just retested by STC and it passes on both platforms. -- David Rothenbergerspammer? -> s...@daveroth.dyndns.org GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734 Pascal: A programming language named after a man who would turn over in his grave if he knew about it. -- Datamation, January 15, 1984 -- 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: {serf,libserf1_0,libserf1-devel}-1.2.0-1
The serf packages have been updated to the new upstream release 1.2.0. See http://serf.googlecode.com/svn/tags/1.2.0/CHANGES for more details about the changes in this release. More information about serf can be found at http://code.google.com/p/serf/. DESCRIPTION: The serf library is a C-based HTTP client library built upon the Apache Portable Runtime (APR) library. It multiplexes connections, running the read/write communication asynchronously. Memory copies and transformations are kept to a minimum to provide high performance operation. DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenbergerspammer? -> s...@daveroth.dyndns.org GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734 Acceptance testing: An unsuccessful attempt to find bugs. -- 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: cyrus-sasl-2.1.26-1
New versions of cyrus-sasl and related packages are available. IMPORTANT NOTE: === The previous 2.1.25-1 package included an ABI change from upstream without updating the DLL names. This can cause problems with other packages that were compiled against the earlier version of cyrus-sasl (e.g., exim or openldap). Users of those packages should downgrade their libsasl2 package to 2.1.23-1 to avoid any problems. This update includes a new libsasl2_3 package that can be installed in parallel with the older libsasl2 package. CYGWIN CHANGES: == * Switch to version-less .cygport file * Remove Cygwin README. * Auto-generate hints. * Run test suite. * Update to db-4.8. * The ABI changed, so include a libsasl2_3 package that can be installed in parallel with the older libsasl2 package. The plug-ins for the new package are stored in /usr/lib/sasl2_3. DESCRIPTION: SASL is the Simple Authentication and Security Layer, a method for adding authentication support to connection-based protocols. To use SASL, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection. See http://cyrusimap.org/ for more information. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenbergerspammer? -> s...@daveroth.dyndns.org GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734 Acceptance testing: An unsuccessful attempt to find bugs. -- 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: STC for fork SEGV after dlclose
On May 29 09:49, David Rothenberger wrote: > Corinna Vinschen wrote: > > On May 28 22:14, David Rothenberger wrote: > >> On 5/27/2013 12:38 PM, Corinna Vinschen wrote: > >>> Other than that, I'll upload a new 32 bit snapshot and a new 64 bit > >>> Cygwin package within the next hour or so. Please give both of them > >>> a try. > >> > >> The libapr1 test suite passes for both 32 bit and 64 bit with the fixes. > >> Thanks! > > > > Cool! Thanks for testing! Also, did you check that fork now works > > as expected in the dlopen/dlclose case on both platforms? > > I hadn't (I figured you probably did) but I just retested by STC and it > passes on both platforms. Thanks for testing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: Using native symlinks
On May 29 12:40, Chris Sutcliffe wrote: > On 29 May 2013 11:23, Corinna Vinschen wrote: > > On May 29 10:33, Chris Sutcliffe wrote: > >> On 29 May 2013 04:39, Corinna Vinschen wrote: > >> > To workaround that, you can either add yourself to the "Create symbolic > >> > links" right, or you can add the "Users" group if you want to allow > >> > every user to create symlinks. But this requires changing it on all > >> > machines manually, so alternatively you can create a domain policy which > >> > adds the trusted users to this user right on all machines. > >> > >> I tried this approach and I'm still not having any luck with the user > >> being able to create native symbolic links in a non-elevated shell. > > > > What approach? Adding the Users group to the Local Security Policy or > > adding a domain policy? If the latter, did you call gpupdate on the > > client or reboot the client machine to propagate the domain policy? > > I've added the specific domain user in the Local Security Policy as I > am not a domain admin (only an admin on the local machine) and as such > cannot propagate a domain policy change. > > > Also, either way, did you logoff and logon so that the "Create symbolic > > links" user right can be added to your user token? Note that your token > > remains unchanged if you didn't exit from your session. Just changing > > the Policy isn't enough, the OS needs achance to create a new user token > > for you containing the user right. > > I've rebooted the machine since making the change and it has had no > affect. Is there something else I need to do? I don't know. I have to try (but not today). Did you try to add the "Users" group to the Local Security Policy entry instead? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: {aprutil1,libaprutil1,libaprutil1-devel}-1.5.2-1
A new version the Apache Portable Runtime utilities library is now available for download. CYGWIN CHANGES: === * Build against latest libdb: db4.8 for Cygwin and db5.3 for Cygwin 64. * Disable PostgreSQL support. * The PostgreSQL package does not provide dynamic libraries, which are required to build the DSO modules. * Switch to version-less cygport file. * Autogenerate hints. Remove README. * Support building for 64-bit Cygwin. * Currently no openldap support. DESCRIPTION: The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations. The primary goal is to provide an API to which software developers may code and be assured of predictable if not identical behaviour regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenbergerspammer? -> s...@daveroth.dyndns.org GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734 Having nothing, nothing can he lose. -- William Shakespeare, "Henry VI" -- 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: Shadowcopy volume block devices
Greetings, Corinna Vinschen! >> > Btw., as a sidenote, are you aware that you can access the filesystem >> > underneath the volume shadow copy as well? >> >> > Try this (note the trailing backslash!): >> >> > $ cd /proc/sys/Device/HarddiskVolumeShadowCopy1/ >> > $ ls >> >> > The only downside is that you can't cd into the root dir of the >> > shadowcopy by using a ".." expression: >> >> > $ cd /proc/sys/Device/HarddiskVolumeShadowCopy1/Users >> > $ cd .. >> > /proc/sys/Device/HarddiskVolumeShadowCopy1: Not a directory. >> > $ cd ../ >> > /proc/sys/Device/HarddiskVolumeShadowCopy1: Not a directory. >> >> > Here the path handling strips off the trailing backslash and what's >> > left is a block device called /proc/sys/Device/HarddiskVolumeShadowCopy1. >> > With that in mind, it's quite usable, though. >> >> Can this be worked around by a symlink or junction point? (I don't have >> access >> to SVC-enabled box yet, sorry.) > How do you workaround the usage of ".." with symlink or junction? > If so, you don't use ".." anymore. Oh, sorry for the noise. While reading the end of your message I forgot, what was in the beginning of it, it seems... -- WBR, Andrey Repin (anrdae...@freemail.ru) 29.05.2013, <22:44> 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: Postinstall Script Errors With Exit Code 128
cygwin-owner at cygwin dot com wrote on 05/29/2013 12:28:30 PM: > From: "Larry Hall (Cygwin)" > To: cygwin at cygwin dot com, > Date: 05/29/2013 12:29 PM > Subject: Re: Postinstall Script Errors With Exit Code 128 > Sent by: cygwin-owner at cygwin dot com > > On 5/29/2013 12:04 PM, Paul.Nickerson wrote: > > > > > I tried each of your suggestions, and they did not help it install. I also > > tried cygcheck again, and it did not run any better. Any other ideas? I'm > > at a loss right now. > > This list has seen the occasional question about AWS and Cygwin in the past > but AFAIK, no one active on the list is using AWS with Cygwin. My best > suggestion at this point is to consult the Amazon folks to get their > input. The fact that cygcheck doesn't run to completion really points to > an issue outside of Cygwin proper, since cygcheck is a vanilla Windows > program. > > -- > Larry I tried removing cygwin1.dll from the bin directory and re-running cygcheck.exe, and it ran to completion. When I ran it, I got the below popup and error, and I have attached the produced output, created with " C:\cygwin\bin>cygcheck -s -v -r -h > cygcheck.out 2>&1". I got the error after the Path: and before SysDir:. --- id.exe - Unable To Locate Component --- This application has failed to start because cygwin1.dll was not found. Re-installing the application may fix this problem. --- OK --- garbled output from 'id' command - no uid= found Looking at cygcheck's source, it looks like after displaying "Warning: cygwin1.dll not found on your path" or "Warning: There are multiple cygwin1.dlls on your path", it runs dump_dodgy_apps() (which gives no output when I get cygcheck to run through to completion), and then it runs dump_sysinfo_services() (which gives the output "Can't find the cygrunsrv utility, skipping services check." when I get cygcheck to run to completion). So, I think that one of these functions hangs when cygwin1.dll is present. I'm thinking dump_dodgy_apps. I tried copying cygcheck.exe to other directories and leaving cygwin1.dll in bin, and cygcheck does not hang when run from other directories. ~ Paul cygcheck-complete.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
Re: cygutils Postinstall Script Errors With Exit Code 128
cygwin-owner at cygwin dot com wrote on 05/29/2013 11:47:20 AM: > From: Reini Urban > To: The Cygwin Mailing List , Charles Wilson > , > Date: 05/29/2013 11:47 AM > Subject: Re: cygutils Postinstall Script Errors With Exit Code 128 > Sent by: cygwin-owner at cygwin dot com > > On Tue, May 28, 2013 at 2:43 Paul.Nickerson wrote: > > Package: cygutils > > cygutils.sh exit code 127 > > Package: man > > man.sh exit code 128 > > I got the cygutils postinstall error also, caused by missing dependencies. > > $ cat /etc/postinstall/cygutils.sh > /usr/bin/update-desktop-database > /usr/bin/update-mime-database /usr/share/mime > > both scripts do not exist, and are no cygutils reqs. > please test against it. > like: > test -f /usr/bin/update-desktop-database && /usr/bin/update-desktop-database > test -f /usr/bin/update-mime-database && /usr/bin/update-mime-database > /usr/share/mime > -- > Reini Urban > http://cpanel.net/ http://www.perl-compiler.org/ Those update-* files do not exist for me either. However, I think my problems are starting before cygutils.sh returns with exit code 127. Are you asking me to test that the files exist before I run them? Or, are you asking the Cygwin maintainers to have their cygutils script do so? ~ Paul -- 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: Postinstall Script Errors With Exit Code 128
On 5/29/2013 3:18 PM, paul.nicker...@desknetinc.com wrote: cygwin-owner at cygwin dot com wrote on 05/29/2013 12:28:30 PM: From: "Larry Hall (Cygwin)" To: cygwin at cygwin dot com, Date: 05/29/2013 12:29 PM Subject: Re: Postinstall Script Errors With Exit Code 128 Sent by: cygwin-owner at cygwin dot com On 5/29/2013 12:04 PM, Paul.Nickerson wrote: I tried each of your suggestions, and they did not help it install. I also tried cygcheck again, and it did not run any better. Any other ideas? I'm at a loss right now. This list has seen the occasional question about AWS and Cygwin in the past but AFAIK, no one active on the list is using AWS with Cygwin. My best suggestion at this point is to consult the Amazon folks to get their input. The fact that cygcheck doesn't run to completion really points to an issue outside of Cygwin proper, since cygcheck is a vanilla Windows program. -- Larry I tried removing cygwin1.dll from the bin directory and re-running cygcheck.exe, and it ran to completion. When I ran it, I got the below popup and error, and I have attached the produced output, created with " C:\cygwin\bin>cygcheck -s -v -r -h > cygcheck.out 2>&1". I got the error after the Path: and before SysDir:. --- id.exe - Unable To Locate Component --- This application has failed to start because cygwin1.dll was not found. Re-installing the application may fix this problem. --- OK --- garbled output from 'id' command - no uid= found Right. That's expected. Looking at cygcheck's source, it looks like after displaying "Warning: cygwin1.dll not found on your path" or "Warning: There are multiple cygwin1.dlls on your path", it runs dump_dodgy_apps() (which gives no output when I get cygcheck to run through to completion), and then it runs dump_sysinfo_services() (which gives the output "Can't find the cygrunsrv utility, skipping services check." when I get cygcheck to run to completion). So, I think that one of these functions hangs when cygwin1.dll is present. I'm thinking dump_dodgy_apps. Possibly. You may have a BLODA problem (http://cygwin.com/acronyms/#BLODA), whether known or unknown. If so, getting rid of it will certainly help. I tried copying cygcheck.exe to other directories and leaving cygwin1.dll in bin, and cygcheck does not hang when run from other directories. Interesting. Maybe there's some Windows permission problems in the directory you were running from? -- 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
[ANNOUNCEMENT] Updated: subversion-1.7.9-2
CYGWIN NEWS: * Switch to version-less .cygport file. * Rebuild against libsasl2_3. * Update to db4.8. * Include a partial fix for UNC paths. This fixes the issues reported in http://cygwin.com/ml/cygwin/2013-05/msg00382.html but does not allow UNC paths on the command-line as described in http://cygwin.com/ml/cygwin/2013-01/msg00061.html. Using UNC paths as command-line arguments requires teaching libapr1 about UNC paths for Cygwin. NEWS: = See CHANGES (URL below) for more information about the differences between 1.7.9 and previous Subversion releases. IMPORTANT: Please read the release notes (URL below) before upgrading from a previous major release. 1.7 includes a new working copy format with a manual upgrade operation. This will render your working copy unusable with previous major releases. Furthermore, there are some issues trying to upgrade corrupt working copies. Please see the release notes http://subversion.apache.org/docs/release-notes/1.7.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.7.9/CHANGES for more details about the changes in 1.7.9. DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/en/1.7/index.html for the latest official release of the Subversion Book. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenbergerspammer? -> s...@daveroth.dyndns.org GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734 Cats, no less liquid than their shadows, offer no angles to the wind. -- 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: regression in subversion with 1.7.18 (and .19)
David Rothenberger wrote: > On 5/27/2013 2:34 PM, David Boyce wrote: >> I've encountered a regression in svn client behavior between Cygwin >> 1.7.17 and 1.7.18. I also tried today's snapshot which doesn't fix it, >> though I suspect the problem is actually in the svn port to Cygwin, >> not the DLL (by way of evidence I downgraded a 1.7.18 install to use >> cygwin1.dll from 1.7.17 and it fails the same way). > > The problem is in the svn port for Cygwin, as you mentioned. When > building svn for Cygwin 1.7, I removed support for DOS paths. This > unintentionally removed support for UNC paths as well. > > I'll see what I can do to restore UNC path support without also enabling > DOS path support. I think the recently release subversion-1.7.9-2 package will fix your problem. It does not fix all uses of UNC paths, especially those passed on the command line (e.g., "svn status //server/share" or "svn export //server/share") because those require teaching libapr1 about UNC paths, which I haven't done (yet?). Still, I think it will support your use case of the config directory on a UNC share. Please give it a shot and let me know. -- David Rothenbergerspammer? -> s...@daveroth.dyndns.org GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734 Consultant, n.: Someone who'd rather climb a tree and tell a lie than stand on the ground and tell the truth. -- 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
gdb aborts after setting "throw" catchpoint
Hi all,
Compiling the following with the cygwin g++-4.5.3:
int global;
int main() {
if (global)
throw global;
return 0;
}
Crashes gdb if a catchpoint is set:
GNU gdb (GDB) 7.6.50.20130408-cvs (cygwin-special)
... snip...
Reading symbols from /home/Ryan/experiments/a.exe...done.
(gdb) catch throw
Catchpoint 1 (throw)
(gdb) r
Starting program: /home/Ryan/experiments/a.exe
[New Thread 10024.0x1480]
[New Thread 10024.0x1758]
warning: SuspendThread failed. (winerr 6)
[Inferior 1 (process 10024) exited normally]
(gdb)
Debugger aborted (core dumped)
Has anybody seen this problem before? Meanwhile, setting a breakpoint on
__cxa_throw works just fine, so at least there's a workaround.
Thoughts?
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
Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On 5/29/2013 11:47 AM, Reini Urban wrote: I got the cygutils postinstall error also, caused by missing dependencies. $ cat /etc/postinstall/cygutils.sh /usr/bin/update-desktop-database /usr/bin/update-mime-database /usr/share/mime both scripts do not exist, and are no cygutils reqs. please test against it. like: test -f /usr/bin/update-desktop-database && /usr/bin/update-desktop-database test -f /usr/bin/update-mime-database && /usr/bin/update-mime-database /usr/share/mime Known issue, waiting for cygport fix. cygutils relies on cygport auto-generating the postinstall scripts which invoke those tools. Cygport does this because the install package contains the following two files: /usr/share/applications/cygstart.desktop /usr/share/mime/packages/cygutils.xml ...and it generates the postinstall script unconditionally (e.g. I can't turn it off) and the generated postinstall scripts themselves call the tools unconditionally. Cygport also automatically adds the packages which contain those tools to the requires: field of the setup.hint, so...under normal circumstances, everything should be fine. However, at user request I've manually removed the requires: line, because the addition of these two files to the cygutils package shouldn't have the effect of pulling *PERL* into the Base category. I assumed we'd live with the semi-brokenness for a few days, until... ...I'm waiting for Yaakov to say whether this should be "fixed" in cygport [1], or if I should override all the auto-generation stuff by manually creating an explicit postinstall script (with suitable tool existence checks) and setup.hint. [1] arguably, cygport is doing the right thing: (1) ensuring that the tools are called to install the two files, and (2) ensuring that the packages which contain those tools are listed in the requires: line. So, I'm not sure what the "correct" fix should be, and am waiting for Yaakov's input. See: http://cygwin.com/ml/cygwin/2013-05/msg00211.html -- Chuck -- 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: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
Sorry for missing this before. On 2013-05-29 17:43, Charles Wilson wrote: Known issue, waiting for cygport fix. cygutils relies on cygport auto-generating the postinstall scripts which invoke those tools. Cygport does this because the install package contains the following two files: /usr/share/applications/cygstart.desktop /usr/share/mime/packages/cygutils.xml ...and it generates the postinstall script unconditionally (e.g. I can't turn it off) and the generated postinstall scripts themselves call the tools unconditionally. Cygport also automatically adds the packages which contain those tools to the requires: field of the setup.hint, so...under normal circumstances, everything should be fine. Right, because packages providing those kind of files usually need those commands to be run in order for them to take effect; see below. However, at user request I've manually removed the requires: line, because the addition of these two files to the cygutils package shouldn't have the effect of pulling *PERL* into the Base category. I assumed we'd live with the semi-brokenness for a few days, until... Perl? I thought it was Python, due to a false positive in the dependency detection with glib2.0, which I fixed on sourceware. But now that you mention it, is cygutils *supposed* to be in Base? It is marked category: Utils, but seems to be pulled into Base only because of cygwin-doc (which *is* in Base, oddly enough; shouldn't it just be Doc?) listing it as a dependency. ...I'm waiting for Yaakov to say whether this should be "fixed" in cygport [1], or if I should override all the auto-generation stuff by manually creating an explicit postinstall script (with suitable tool existence checks) and setup.hint. The "problem" here is that cygutils is not primarily a desktop-oriented package. Most packages providing XDG menu and mime entries *are*, so these dependencies not only mandatory, but quite modest by those standards. I added these files because it allows better integration between desktop file managers (Nautilus/Caja/Thunar/PCManFM/Dolphin/etc.) and Windows, e.g. making it easy to launch an EXE/MSI installer from one's Downloads folder. However, most people use cygutils outside of the desktop, so particularly if its pulled into Base, these deps would be more than the bare-minimal system. If cygutils should be in Base, the "solution" is probably one of the following: * provide these files (and postinstall scripts) in a 'cygutils-x11' subpackage; * OR move them to another package (not sure which yet) which will already be installed in desktop scenarios, and adding cygutils as a dependency thereto. For now, should we go with the first option? 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: Using native symlinks
On 29 May 2013 13:01, Corinna Vinschen wrote: > On May 29 12:40, Chris Sutcliffe wrote: >> On 29 May 2013 11:23, Corinna Vinschen wrote: >> > On May 29 10:33, Chris Sutcliffe wrote: >> >> On 29 May 2013 04:39, Corinna Vinschen wrote: >> > Also, either way, did you logoff and logon so that the "Create symbolic >> > links" user right can be added to your user token? Note that your token >> > remains unchanged if you didn't exit from your session. Just changing >> > the Policy isn't enough, the OS needs achance to create a new user token >> > for you containing the user right. >> >> I've rebooted the machine since making the change and it has had no >> affect. Is there something else I need to do? > > I don't know. I have to try (but not today). Did you try to add the > "Users" group to the Local Security Policy entry instead? I tried adding the "Users" group and it didn't help either. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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: regression in subversion with 1.7.18 (and .19)
On Wed, May 29, 2013 at 1:38 PM, David Rothenberger wrote: > I think the recently release subversion-1.7.9-2 package will fix your > problem. It does not fix all uses of UNC paths, especially those passed > on the command line (e.g., "svn status //server/share" or "svn export > //server/share") because those require teaching libapr1 about UNC paths, > which I haven't done (yet?). > > Still, I think it will support your use case of the config directory on > a UNC share. > > Please give it a shot and let me know. My local test case now works perfectly. Thanks! -David Boyce -- 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
sqlite3: bug with monotone
Warren, I'm having a problem with my newly built monotone packages on both x86 and x64: mtn: warning: recoverable 'system' error while processing peer mtn://monotone.ca/monotone: 'error: sqlite error: SQL logic error or missing database' mtn: error: processing failure while talking to peer 'mtn://monotone.ca/monotone', disconnecting This was working properly with my 3.7.15.2 x64 package, as well as with a self-built 3.7.17. I don't know if it's a question of configuration options or a bug in that version. Here's how I have built sqlite3: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/sqlite3;a=tree Could you please provide an update for both arches? 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] Updated: botan-1.8.14-1
The following packages have been updated in the Cygwin distribution: *** libbotan1.8.13-1.8.14-1 *** libbotan-devel-1.8.14-1 (replaces the 'botan' package) Botan is a crypto library for C++ released under the permissive 2-clause BSD license. It provides most any cryptographic algorithm you might be looking for, along with Transport Layer Security (TLS), X.509 certs, CRLs, and path validation, a pipeline-style message processing system, bcrypt password hashing, and other useful things. This is an update to the latest release in the 1.8 branch, used by the latest official release of monotone. All optional features are enabled, and the shared library is now available. The i686 release was built with gcc-4.7, currently in testing. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: gdb aborts after setting "throw" catchpoint
On 2013-05-29 23:23, Ryan Johnson wrote: GNU gdb (GDB) 7.6.50.20130408-cvs (cygwin-special) ... snip... Reading symbols from /home/Ryan/experiments/a.exe...done. (gdb) catch throw Catchpoint 1 (throw) That was a mistake in the documentation, they didn't actually get around to implementing it. They have since rectified that mistake, but it's only going to be in version 7.7 See bug: http://sourceware.org/bugzilla/show_bug.cgi?id=13588 -- 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
