RFU: sqlite 3.6.21-3
This fixes a b0rked source patch -1 and -2, which should be removed. wget -e robots=off --cut-dirs=2 -np -nH -A'*3.6.21-3*' -r \ http://etr-usa.com/cygwin/sqlite3/ Yes, I'm aware that I should be testing these packages better. No need to tell me I am a doofus. I already know that.
RFU: doxygen 1.6.1-2
This fixes some packaging errors in -1 and adds manpages to the package. wget -e robots=off --cut-dirs=2 -np -nH -A'*1.6.1-2*' -r \ http://etr-usa.com/cygwin/doxygen/ Previous -1 should be removed.
Re: 1.7 installation failed (on network drive?)
On Dec 17 14:38, Corinna Vinschen wrote: > On Dec 17 14:09, Corinna Vinschen wrote: > > Has the H:\cygwin17 directory been created at all? If so, we should > > examine the cacls for this dir just like the cacls for H:\ itself. > > > > Hmm. > > > > [...time passes...] > > > > Hang on, there's another possible reason for STATUS_ACCESS_DENIED. > > Mkdir_p calls NtCreateFile to create the directory with > > STANDARD_RIGHTS_ALL rights. This includes WRITE_DAC and WRITE_OWNER > > rights. Especially the last one could be a problem for a non-admin > > user. > > > > Could you please try to replace STANDARD_RIGHTS_ALL with > > > > SYNCHRONIZE | WRITE_DAC | READ_CONTROL > > > > If that works, we're done. If that doesn't work, try > > > > SYNCHRONIZE | READ_CONTROL > > > > If that works, you will see failure log output from SetPosixPerms(). > > > > Either way, this might be the entire problem here. If the first > > expression works, we should be able to use it as is. If only the > > second expression works, we have to do some admin/non-admin conditional. > > Good news. I can finally reproduce the problem. Digging deeper now... It turned out that even the WRITE_DAC access can result in an access denied error on a share if the user is not an admin user, even though the file is owned by the creator. This can also be observed when you open the file's properties dialog and visit the security tab. While you can press the "Edit..." button (it's not grayed out) you can not edit the DACL despite being the owner of the file. Go figure! I applied a patch which falls back to opening/creating the file/dir without WRITE_DAC if the first call failed. That's not quite optimal but it works. Please check out the latest from CVS and test in your scenario. For me it works now on the share as well as on local drives. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
On Dec 17 10:52, Christopher Faylor wrote: > On Thu, Dec 17, 2009 at 02:12:15PM +0100, Corinna Vinschen wrote: > >On Dec 16 13:40, Christopher Faylor wrote: > >> On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote: > >> >But we discussed this on the developers list. The old setup will be > >> >setup-legacy.exe and setup.exe is only for 1.7 and later. I'm rather > >> >puzzled that you want to change this again. I have matching local > >> >changes to the web page waiting. Please don't change this again. > >> > >> Since I have to change source code to understand the "release-legacy" > >> directory, I opted to just do it in the trunk rather than the ancient > >> setup 1.5 branch. There will still be a setup-legacy binary. > > > >Ok. The problem is just this. If setup.exe still works for 9x users > >and just access setup-legacy.ini, they will never see that they are > >accessing an unsupported repository. That's why I now think that > >setup.exe should give them a warning instead. They should explicitely > >be forced to use setup-legacy.exe if they updated at all. > > "There will still be a setup-legacy binary" != "setup.exe will seem to > work just fine for Windows 9x users". You wrote that you would like setup to work on 9x again and that's what I'm talking about. I didn't mean to imply anything about setup-legacy. It's all about setup. Details might be helpful. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
On Thu, Dec 17, 2009 at 02:12:15PM +0100, Corinna Vinschen wrote: >On Dec 16 13:40, Christopher Faylor wrote: >> On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote: >> >But we discussed this on the developers list. The old setup will be >> >setup-legacy.exe and setup.exe is only for 1.7 and later. I'm rather >> >puzzled that you want to change this again. I have matching local >> >changes to the web page waiting. Please don't change this again. >> >> Since I have to change source code to understand the "release-legacy" >> directory, I opted to just do it in the trunk rather than the ancient >> setup 1.5 branch. There will still be a setup-legacy binary. > >Ok. The problem is just this. If setup.exe still works for 9x users >and just access setup-legacy.ini, they will never see that they are >accessing an unsupported repository. That's why I now think that >setup.exe should give them a warning instead. They should explicitely >be forced to use setup-legacy.exe if they updated at all. "There will still be a setup-legacy binary" != "setup.exe will seem to work just fine for Windows 9x users". cgf
Re: 1.7 installation failed (on network drive?)
Corinna Vinschen wrote: On Dec 17 14:09, Corinna Vinschen wrote: Has the H:\cygwin17 directory been created at all? If so, we should examine the cacls for this dir just like the cacls for H:\ itself. No, it hasn't. For some ACLs, see below. Hmm. [...time passes...] Hang on, there's another possible reason for STATUS_ACCESS_DENIED. Mkdir_p calls NtCreateFile to create the directory with STANDARD_RIGHTS_ALL rights. This includes WRITE_DAC and WRITE_OWNER rights. Especially the last one could be a problem for a non-admin user. I looked up what these two mean and in fact it sounds like the problem; I had previously sent the output of getfacl on the drive directories and on directories manually created there, don't know if that helps: Also here is the output of getfacl for directories on the two network drives I had tried: > # file: /cygdrive/h > # owner: Administratoren > # group: > user::rwx > user:wolff:rwx > group::--- > group:SYSTEM:rwx > mask:rwx > other:--- > default:user::rwx > default:user:Administratoren:rwx > default:user:wolff:rwx > default:group:SYSTEM:rwx > default:mask:rwx > > # file: /cygdrive/h/cygwin > # owner: wolff > # group: Domänen-Benutzer > user::rwx > group::--- > group:root:rwx > group:SYSTEM:rwx > mask:rwx > other:--- > default:user::rwx > default:user:wolff:rwx > default:group:root:rwx > default:group:SYSTEM:rwx > default:mask:rwx > # file: /cygdrive/t/TGI > # owner: Administratoren > # group: > user::rwx > group::--- > group:SYSTEM:rwx > group:Benutzer:r-x > mask:rwx > other:--- > default:user::rwx > default:user:Administratoren:rwx > default:group:SYSTEM:rwx > default:group:Benutzer:r-x > default:mask:rwx > > # file: /cygdrive/t/TGI/cygwin > # owner: Administratoren > # group: > user::rwx > group::--- > group:SYSTEM:rwx > group:Benutzer:r-x > mask:rwx > other:--- > default:user::rwx > default:user:Administratoren:rwx > default:group:SYSTEM:rwx > default:group:Benutzer:r-x > default:mask:rwx Also, speaking of ACLs and pondering about possible effects of their inheritance, it comes to my mind that it might make a difference whether to create H:\cygwin in a mounted H: drive or H:\mydir\cygwin so I'll try that next time. Could you please try to replace STANDARD_RIGHTS_ALL with SYNCHRONIZE | WRITE_DAC | READ_CONTROL If that works, we're done. If that doesn't work, try SYNCHRONIZE | READ_CONTROL If that works, you will see failure log output from SetPosixPerms(). Either way, this might be the entire problem here. If the first expression works, we should be able to use it as is. If only the second expression works, we have to do some admin/non-admin conditional. Good news. I can finally reproduce the problem. Digging deeper now... Great, so I'll wait. Concerning "time until release", if you want me to test something tomorrow morning that's OK, if you want me to test something today, please provide compiled debug versions somewhere on the net as I cannot compile it here. Thomas
Re: 1.7 installation failed (on network drive?)
On Dec 17 14:09, Corinna Vinschen wrote: > Has the H:\cygwin17 directory been created at all? If so, we should > examine the cacls for this dir just like the cacls for H:\ itself. > > Hmm. > > [...time passes...] > > Hang on, there's another possible reason for STATUS_ACCESS_DENIED. > Mkdir_p calls NtCreateFile to create the directory with > STANDARD_RIGHTS_ALL rights. This includes WRITE_DAC and WRITE_OWNER > rights. Especially the last one could be a problem for a non-admin > user. > > Could you please try to replace STANDARD_RIGHTS_ALL with > > SYNCHRONIZE | WRITE_DAC | READ_CONTROL > > If that works, we're done. If that doesn't work, try > > SYNCHRONIZE | READ_CONTROL > > If that works, you will see failure log output from SetPosixPerms(). > > Either way, this might be the entire problem here. If the first > expression works, we should be able to use it as is. If only the > second expression works, we have to do some admin/non-admin conditional. Good news. I can finally reproduce the problem. Digging deeper now... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
On Dec 16 13:40, Christopher Faylor wrote: > On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote: > >But we discussed this on the developers list. The old setup will be > >setup-legacy.exe and setup.exe is only for 1.7 and later. I'm rather > >puzzled that you want to change this again. I have matching local > >changes to the web page waiting. Please don't change this again. > > Since I have to change source code to understand the "release-legacy" > directory, I opted to just do it in the trunk rather than the ancient > setup 1.5 branch. There will still be a setup-legacy binary. Ok. The problem is just this. If setup.exe still works for 9x users and just access setup-legacy.ini, they will never see that they are accessing an unsupported repository. That's why I now think that setup.exe should give them a warning instead. They should explicitely be forced to use setup-legacy.exe if they updated at all. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: 1.7 installation failed (on network drive?)
On Dec 17 12:17, Thomas Wolff wrote: > Corinna Vinschen wrote: > >On Dec 17 02:12, Thomas Wolff wrote: > >>I took an extra drive to the lab this afternoon, with no good results. > >>[...] > >>mkdir:NtCreateFile -> 0 > >> > >> <\??\D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f> > >>filemanip:NtCreateFile -> 0 > >> > >> <\??\D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f\setup-2.ini> > >>mkdir:NtCreateFile -> C022 > > > >This appears to be the actual start of the desaster. > I guess I should have made clear that the trace of the filename > comes *after* the trace of the status in my logs, sorry. So in this > log, it's: > mkdir:NtCreateFile -> C022 > <\??\H:\cygwin17\etc\setup> No, that was quite clear. I just got out of sync when reading the log output. > Anyway, this complies with the fact that's it's the network drive H: > giving the problems, not D: which is a local drive. > So I think I should apply all your instructions to > H:\cygwin17\etc\setup, or to H:\cygwin17p in the reverse test case: > mkdir:NtCreateFile -> C022 > <\??\H:\cygwin17p> Just keep everything as it is. The problem is that you get a C022, STATUS_ACCESS_DENIED. I can only reprocude this if I really have no right to create a directory. Has the H:\cygwin17 directory been created at all? If so, we should examine the cacls for this dir just like the cacls for H:\ itself. Hmm. [...time passes...] Hang on, there's another possible reason for STATUS_ACCESS_DENIED. Mkdir_p calls NtCreateFile to create the directory with STANDARD_RIGHTS_ALL rights. This includes WRITE_DAC and WRITE_OWNER rights. Especially the last one could be a problem for a non-admin user. Could you please try to replace STANDARD_RIGHTS_ALL with SYNCHRONIZE | WRITE_DAC | READ_CONTROL If that works, we're done. If that doesn't work, try SYNCHRONIZE | READ_CONTROL If that works, you will see failure log output from SetPosixPerms(). Either way, this might be the entire problem here. If the first expression works, we should be able to use it as is. If only the second expression works, we have to do some admin/non-admin conditional. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: 1.7 installation failed (on network drive?)
Corinna Vinschen wrote: On Dec 17 02:12, Thomas Wolff wrote: I took an extra drive to the lab this afternoon, with no good results. [...] mkdir:NtCreateFile -> 0 <\??\D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f> filemanip:NtCreateFile -> 0 <\??\D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f\setup-2.ini> mkdir:NtCreateFile -> C022 This appears to be the actual start of the desaster. I guess I should have made clear that the trace of the filename comes *after* the trace of the status in my logs, sorry. So in this log, it's: mkdir:NtCreateFile -> C022 <\??\H:\cygwin17\etc\setup> Anyway, this complies with the fact that's it's the network drive H: giving the problems, not D: which is a local drive. So I think I should apply all your instructions to H:\cygwin17\etc\setup, or to H:\cygwin17p in the reverse test case: mkdir:NtCreateFile -> C022 <\??\H:\cygwin17p> The problem is that the above alone gives us no clue about the real reason for the access denied error. It's quite puzzeling that there's no log from NTSecurity::SetPosixPerms(), so setting the permissions worked fine, apparently. That's quite clear because after return status C0*22, SetPosixPerms will not be called as it is guarded by if (NT_SUCCESS (status)) Maybe I'll be able to test again tomorrow. What about the option to use mkdir (the normal one from libc) rather than NtCreateFile? I think there were some considerations about assigning backup flags but maybe that's not needed for directories? Thomas Here's what we need next: - Who are you (Windows user and primary group name)? - Output of `cacls D:\' - In GDB, set a breakpoint on mkdir_p and stop right at the point above, *before* NtCreateFile gets called. - What are the permission bits given to the mkdir_p call above? - Output of `cacls D:\cygwin17p' right before the NtCreateFile call. - Output of `cacls D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f' right after the NtCreateFile call but *before* the call to nt_sec.SetPosixPerms(). - Output of `cacls D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f' right after the nt_sec.SetPosixPerms() call. Corinna
Re: ITP: steghide 0.5.1-1
On Dec 10 18:31, Jari Aalto wrote: > wget \ > http://cante.net/~jaalto/tmp/cygwin/steghide/setup.hint \ > http://cante.net/~jaalto/tmp/cygwin/steghide/steghide-0.5.1-1-src.tar.bz2 > \ > http://cante.net/~jaalto/tmp/cygwin/steghide/steghide-0.5.1-1.tar.bz2 Uploaded. Please don't forget to announce. You also still have to announce the rc package. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: 1.7 installation failed (on network drive?)
On Dec 17 02:12, Thomas Wolff wrote: > I took an extra drive to the lab this afternoon, with no good results. > [...] > mkdir:NtCreateFile -> 0 > > <\??\D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f> > filemanip:NtCreateFile -> 0 > > <\??\D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f\setup-2.ini> > mkdir:NtCreateFile -> C022 This appears to be the actual start of the desaster. The problem is that the above alone gives us no clue about the real reason for the access denied error. It's quite puzzeling that there's no log from NTSecurity::SetPosixPerms(), so setting the permissions worked fine, apparently. Here's what we need next: - Who are you (Windows user and primary group name)? - Output of `cacls D:\' - In GDB, set a breakpoint on mkdir_p and stop right at the point above, *before* NtCreateFile gets called. - What are the permission bits given to the mkdir_p call above? - Output of `cacls D:\cygwin17p' right before the NtCreateFile call. - Output of `cacls D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f' right after the NtCreateFile call but *before* the call to nt_sec.SetPosixPerms(). - Output of `cacls D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f' right after the nt_sec.SetPosixPerms() call. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: general setup.exe status incl network install [was Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...]
On Dec 17 01:33, Dave Korn wrote: > I think the strace suggests where the problem lies: > > > 350 519655 [main] bash 680 open: 3 = open (/tmp/sh-thd-1261038922, > > 0x10E01) >[ ... snip ... ] > > 517 535090 [main] bash 680 open: 4 = open (/tmp/sh-thd-1261038922, > > 0x1) > > 454 535544 [main] bash 680 close: close (3) > > 476 536020 [main] bash 680 fhandler_base::close: closing > > '/tmp/sh-thd-1261038922' handle 0x6A4 > > 679 536699 [main] bash 680 close: 0 = close (3) > > 563 537262 [main] bash 680 normalize_posix_path: src > > /tmp/sh-thd-1261038922 > > 605 537867 [main] bash 680 normalize_posix_path: /tmp/sh-thd-1261038922 > > = normalize_posix_path (/tmp/sh-thd-1261038922) > > 449 538316 [main] bash 680 mount_info::conv_to_win32_path: > > conv_to_win32_path (/tmp/sh-thd-1261038922) > > 571 538887 [main] bash 680 set_flags: flags: binary (0x2) > > 806 539693 [main] bash 680 mount_info::conv_to_win32_path: src_path > > /tmp/sh-thd-1261038922, dst Z:\cygremotewin2\tmp\sh-thd-1261038922, flags > > 0x3000A, rc 0 > > 1641 541334 [main] bash 680 symlink_info::check: not a symlink > > 1003 542337 [main] bash 680 symlink_info::check: 0 = symlink.check > > (Z:\cygremotewin2\tmp\sh-thd-1261038922, 0x22B5E8) (0x3000A) > > 466 542803 [main] bash 680 path_conv::check: > > this->path(Z:\cygremotewin2\tmp\sh-thd-1261038922), has_acls(1) > > 547 543350 [main] bash 680 seterrno_from_win_error: > > /ext/build/netrel/src/cygwin-1.7.0-62/winsup/cygwin/syscalls.cc:674 windows > > error 32 > > 496 543846 [main] bash 680 geterrno_from_win_error: windows error 32 == > > errno 16 > > 449 544295 [main] bash 680 __set_errno: void > > seterrno_from_win_error(const char*, int, DWORD):319 val 16 > > 433 544728 [main] bash 680 unlink: -1 = unlink (/tmp/sh-thd-1261038922) > > 740 545468 [main] bash 680 close: close (4) > > 498 545966 [main] bash 680 fhandler_base::close: closing > > '/tmp/sh-thd-1261038922' handle 0x6A0 > > 1121 547087 [main] bash 680 close: 0 = close (4) > > It looks like the unlink-while-you-still-have-an-open-handle-to-the-file > trick isn't working on SMB mounts, perhaps? Indeed. unlink-while-you-still-have-an-open-handle-to-the-file requires to be able to move the file to the recycle bin. The recycle bin does not exist on shares. So you get an EBUSY which is perfectly fine with POSIX. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
