Re: [ITP] Sendmail 8.14.9
On Aug 25 18:16, Yaakov Selkowitz wrote: On 2014-08-24 01:35, D. Boland wrote: About the 64bit version: Are there any things I have to be careful of? Like crosscompiling? Or is it a matter of just straight forward compiling on a 64bit Cygwin machine? Hopefully the latter, but sometimes it's not that simple, so be sure to test the resulting binaries. The most simple thing to do is to install 64 bit Cygwin and do the port natively. Many projects have no provisions for cross-compiling, mostly non-autotools or non-cmake projects. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpsjpEi6oRkW.pgp Description: PGP signature
RE: [ITP] Sendmail 8.14.9
-Original Message- From: Yaakov Selkowitz Sent: Friday, August 22, 2014 17:40 On 2014-08-22 13:19, D. Boland wrote: On Aug 22 07:43, D. Boland wrote: I re-packaged Sendmail with cygport. See: http://cygwin.boland.nl/x86/release/sendmail/ Packaging looks good in theory. Unfortunately we have a problem. On inspection of your binary package I noticed that we have conflicts with exim and ssmtp packages: [snip] What we'll have to do to fix this problem is to convert all three packages to use alternatives. The alternatives package exists and is already used by a couple of other packages which would otherwise conflict, so there's precendent. And on Fedora, the various mail packages all use alternatives, too, to install their packages in parallel and conflict-free. [snip] Why not let the user choose one program? Putting both Exim and Sendmail on one box is confusing, to say the least. Sendmail is very tough to understand. You don't want another (very similar looking) mail exchanger to add to the confusion. Cygwin's setup*.exe does not support the concept of conflicts (one package blocking others from being installed), nor does it prevent file clobbering if multiple packages provide the same file. Since there is no way to stop multiple MTAs from being installed, it is necessary to insure that they do so properly. This needs to be handled properly, that's all, and that can take time. If Pierre doesn't respond soon, we can step in to help with exim. I should have time one evening this week to do whatever it takes. However I am not sure we need alternatives to handle conflicts in this case. In the exim package /usr/bin/mailq and /usr/bin/newaliases are just symbolic links to exim (newaliases is just a noop provided only to keep some 3rd party scripts from failing). It would be easy to pull them out of the package and to recreate them under user control in the exim config script. Hopefully other MTAs can do something similar. The symbolic link /usr/sbin/sendmail is not used by exim. It can be set from the exim config script to allow third party programs to find the local MTA. Whatever we do should be transparent to users who have already installed ssmtp or exim and are updating to a newer version. Pierre
Re: [ITP] Sendmail 8.14.9
On Aug 26 09:51, Pierre A. Humblet wrote: -Original Message- From: Yaakov Selkowitz Sent: Friday, August 22, 2014 17:40 On 2014-08-22 13:19, D. Boland wrote: On Aug 22 07:43, D. Boland wrote: I re-packaged Sendmail with cygport. See: http://cygwin.boland.nl/x86/release/sendmail/ Packaging looks good in theory. Unfortunately we have a problem. On inspection of your binary package I noticed that we have conflicts with exim and ssmtp packages: [snip] What we'll have to do to fix this problem is to convert all three packages to use alternatives. The alternatives package exists and is already used by a couple of other packages which would otherwise conflict, so there's precendent. And on Fedora, the various mail packages all use alternatives, too, to install their packages in parallel and conflict-free. [snip] Why not let the user choose one program? Putting both Exim and Sendmail on one box is confusing, to say the least. Sendmail is very tough to understand. You don't want another (very similar looking) mail exchanger to add to the confusion. Cygwin's setup*.exe does not support the concept of conflicts (one package blocking others from being installed), nor does it prevent file clobbering if multiple packages provide the same file. Since there is no way to stop multiple MTAs from being installed, it is necessary to insure that they do so properly. This needs to be handled properly, that's all, and that can take time. If Pierre doesn't respond soon, we can step in to help with exim. I should have time one evening this week to do whatever it takes. However I am not sure we need alternatives to handle conflicts in this case. In the exim package /usr/bin/mailq and /usr/bin/newaliases are just symbolic links to exim (newaliases is just a noop provided only to keep some 3rd party scripts from failing). It would be easy to pull them out of the package and to recreate them under user control in the exim config script. Hopefully other MTAs can do something similar. The symbolic link /usr/sbin/sendmail is not used by exim. It can be set from the exim config script to allow third party programs to find the local MTA. Whatever we do should be transparent to users who have already installed ssmtp or exim and are updating to a newer version. I guess that's exactly the problem. Consider somebody has installed exim or ssmtp and then installs sendmail accidentally or out of curiosity. This immediately overwrites the symlinks and even if the user never actually uses sendmail, the MTA installation is broken. I don't have a clear concept yet if and how we should use alternatives to fix this problem. Anyway, to have some working example, here's how Fedora does it: The binaries, or symlinks to the actual binaries are called: /usr/sbin/sendmail.sendmail /usr/bin/mailq.sendmail /usr/bin/newaliases.sendmail /usr/sbin/sendmail.exim /usr/bin/mailq.exim /usr/bin/newaliases.exim /usr/sbin/sendmail.postfix /usr/bin/mailq.postfix /usr/bin/newaliases.postfix [analog for other MTAs] Sendmail, mailq, newalias (etc.) are alternatives symlinks: /usr/sbin/sendmail - /etc/alternatives/mta /usr/bin/mailq - /etc/alternatives/mta-mailq /usr/bin/newaliases - /etc/alternatives/mta-newaliases And in /etc/alternatives are the symlinks to the actual binaries, as configured by postinstall or the user: /etc/alternatives/mta - /usr/sbin/sendmail.exim /etc/alternatives/mta-mailq - /usr/bin/mailq.exim /etc/alternatives/mta-newaliases - /usr/bin/newaliases.exim In fact, there are more than these three symlinks, mainly to rmail and to the man pages for the aforementioned binaries. Maybe we can shamelessly borrow this scheme?!? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpvJYCiG2QOp.pgp Description: PGP signature
src/winsup/cygwin path.h fhandler_disk_file.cc ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-08-26 20:47:47 Modified files: winsup/cygwin : path.h fhandler_disk_file.cc syscalls.cc ntea.cc security.cc ChangeLog Log message: * path.h (path_conv::init_reopen_attr): Change from void to returning POBJECT_ATTRIBUTES. Take OBJECT_ATTRIBUTES reference as argument, not pointer. * fhandler_disk_file.cc: Throughout accommodate above change. * syscalls.cc: Ditto. * ntea.cc (read_ea): Don't set hdl to NULL if it's already NULL. Set attr with pc.init_reopen_attr before trying to reopen file. (write_ea): Ditto. * security.cc (get_file_sd): Use pc.init_reopen_attr rather than pc.get_object_attr when trying to reopen file. (set_file_sd): Ditto. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.h.diff?cvsroot=srcr1=1.182r2=1.183 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.399r2=1.400 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.665r2=1.666 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ntea.cc.diff?cvsroot=srcr1=1.31r2=1.32 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/security.cc.diff?cvsroot=srcr1=1.267r2=1.268 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6506r2=1.6507
Re: (call-process ...) hangs in emacs
On Mon, Aug 25, 2014 at 8:00 PM, Ken Brown kbr...@cornell.edu wrote: It looks like my idea is going to work, but it needs testing to make sure I've implemented it correctly. If anyone is willing to test it, you can download emacs-24.3.93-2 from my personal Cygwin repository: I've downloaded it - no problems so far but I'll run with it from now on and let know you if anything untoward happens. Pete -- 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: Why does df fail to stat CIFS shares?
Corinna Vinschen corinna-cygwin at cygwin.com writes: That's the real output? No error message, just the names of the mount points? Is that the 32 or 64 bit Cygwin? Yes: df /home/gratz df: ‘/home/gratz’ Given the lack of access to netapp drives, if this is a bug in Cygwin (which seems likely in this case) I would need your cooperation to run debugging sessions to be able to come up with a fix. Is that ok? Sorry, can't do that. For a start, could you run `strace -o df.strace df' and attach the df.strace file to your reply? My home dir is on a NetApp. This one's mounted with ACL, but the same happens for volumes that are mounted noacl. /usr/lib/csih/getVolInfo /home/gratz Device Type: 7 Characteristics: 10 Volume Name: CIFS.HOMEDIR Serial Number : 0 Max Filenamelength : 255 Filesystemname : NTFS Flags : 4004f FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE The interesting part of the trace is this: 37 2532956 [main] df 15880 get_info_from_sd: ACL 0x41C0, uid 1124017, gid 1049089 54 2533010 [main] df 15880 fhandler_base::fstat_helper: 0 = fstat (\??\H:\GNU, 0x22AA00) st_size=0, st_mode=0x41C0, st_ino=-891439913066804700st_atim=53FB5E84.243D9E50 st_ctim=53F5EE0B.37D76CE8 st_mtim=53F5EE0B.37D76CE8 st_birthtim=3FB9EC6D.0 39 2533049 [main] df 15880 stat_worker: 0 = (\??\H:\GNU,0x22AA00) 2857 2535906 [main] df 15880 normalize_posix_path: src /home/gratz 57 2535963 [main] df 15880 normalize_posix_path: /home/gratz = normalize_posix_path (/home/gratz) 39 2536002 [main] df 15880 mount_info::conv_to_win32_path: conv_to_win32_path (/home/gratz) 33 2536035 [main] df 15880 set_flags: flags: binary (0x2) 32 2536067 [main] df 15880 mount_info::conv_to_win32_path: src_path /home/gratz, dst H:\GNU, flags 0x2, rc 0 1289 2537356 [main] df 15880 symlink_info::check: 0x0 = NtCreateFile (\??\H:\GNU) 3159 2540515 [main] df 15880 symlink_info::check: not a symlink 1814 2542329 [main] df 15880 symlink_info::check: 0 = symlink.check(H:\GNU, 0x229330) (0x2) 59 2542388 [main] df 15880 path_conv::check: this-path(H:\GNU), has_acls(1) 49 2542437 [main] df 15880 build_fh_pc: fh 0x180331B38, dev 00C3 28 2542465 [main] df 15880 statvfs: (/home/gratz, 0x22A5E0), file_attributes 48 1404 2543869 [main] df 15880 fhandler_disk_file::fstatvfs: 0xC00D = NtQueryVolumeInformationFile(\??\H:\GNU, FileFsFullSizeInformation) 2918 2546787 [main] df 15880 fhandler_disk_file::fstatvfs: -1 = fstatvfs(/home/gratz, 0x22A5E0) 71 2546858 [main] df 15880 statvfs: -1 = statvfs(/home/gratz,0x22A5E0), errno 0 1201 2548059 [main] df 15880 fhandler_pty_slave::write: pty1, write(0x22AB30, 2) 60 2548119 [main] df 15880 fhandler_pty_slave::write: (656): pty output_mutex (0x190): waiting -1 ms 43 2548162 [main] df 15880 fhandler_pty_slave::write: (656): pty output_mutex: acquired 43 2548205 [main] df 15880 fhandler_pty_slave::write: (671): pty output_mutex(0x190) released 34 2548239 [main] df 15880 write: 2 = write(2, 0x22AB30, 2) 66 2548305 [main] df 15880 fhandler_pty_slave::write: pty1, write(0x18022ADE1, 1) 37 2548342 [main] df 15880 fhandler_pty_slave::write: (656): pty output_mutex (0x190): waiting -1 ms 47 2548389 [main] df 15880 fhandler_pty_slave::write: (656): pty output_mutex: acquired 40 2548429 [main] df 15880 fhandler_pty_slave::write: (671): pty output_mutex(0x190) released 34 2548463 [main] df 15880 write: 1 = write(2, 0x18022ADE1, 1) 62 2548525 [main] df 15880 fhandler_pty_slave::write: pty1, write(0x18022ADD5, 1) 38 2548563 [main] df 15880 fhandler_pty_slave::write: (656): pty output_mutex (0x190): waiting -1 ms 56 2548619 [main] df 15880 fhandler_pty_slave::write: (656): pty output_mutex: acquired 39 2548658 [main] df 15880 fhandler_pty_slave::write: (671): pty output_mutex(0x190) released 34 2548692 [main] df 15880 write: 1 = write(2, 0x18022ADD5, 1) 307 2548999 [main] df 15880 fhandler_pty_slave::write: pty1, write(0x10041C0C0, 17) 40 2549039 [main] df 15880 fhandler_pty_slave::write: (656): pty output_mutex (0x190): waiting -1 ms 41 2549080 [main] df 15880 fhandler_pty_slave::write: (656): pty output_mutex: acquired 39 2549119 [main] df 15880 fhandler_pty_slave::write: (671): pty output_mutex(0x190) released 34 2549153 [main] df 15880 write: 17 = write(2, 0x10041C0C0, 17) 577 2549730 [main] df 15880 fhandler_pty_slave::write: pty1,
Re: setup.exe handles same packages in multiple mirrors badly
On Aug 26 05:35, Andrey Repin wrote: Greetings, Bjorn Kautler! But first things first, it is Bjorn or Bjoern, not Bjorn. :-) Apology. My current locale does not include western diacritics. Now I only wanted to update the git packages, so I selected Keep in the upper right corner, That's the worst thing you could possible do. It changes so many states on so many packages at once, that the result is hardly predictable. filtered for git in the upper left and then cycled in the New column and only got the entries Keep, 1.8.5.5-1 and Uninstall. If I now instead select Curr in the upper right, the git packages have 2.0.4-1 selected in New column. If I now cycle through the possibilities I still keep only getting Keep, 1.8.5.5-1 and Uninstall. The only way to get 2.0.4-1 back in that column is to deselect Curr and select Curr again. If you ask me, Setup is long overdue for a complete replacement. It don't have so many things other package managers allow, that I don't even know, where to start. Meta dependencies? Suggestions? Virtual packages? The problem is not that we don't know this, the problem is, as so often, that we only have a handful of active developers at all, and nobody having the time nor inclination to work on setup to keep it ahead of time. Setup was a wonderful idea, way back when it has been created, but the vintage charm of its Y2K roots are a bit depressing these days. So, if anybody wants to take a stab at setup and revamp it, feel free. The only requirements are, it should still be able to utilize the setup.ini file created on cygwin.com, it should still be able to work the mirror list provided by cygwin.com, and it should still provide a GUI and a command line. Everything else is open for renewal. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpth3VODjbu0.pgp Description: PGP signature
[ANNOUNCEMENT] Updated: procps-3.2.8-3
I updated the 32 bit procps package to 3.2.8-4. This fixes my accidental upload of a 64 bit 3.2.8-3 package into the 32 bit release. Sorry, 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
Fwd: setup.exe handles same packages in multiple mirrors badly
Greetings, Bjorn Kautler! But first things first, it is Bjorn or Bjoern, not Bjorn. :-) Apology. My current locale does not include western diacritics. Sure, that is why you can say Bjoern, which is the correct transliteration. But NOT Bjorn, that is not my name, so please stop using it. :-) Now I only wanted to update the git packages, so I selected Keep in the upper right corner, That's the worst thing you could possible do. It changes so many states on so many packages at once, that the result is hardly predictable. Oh, ok. Could you maybe elaborate more on this? What else does this do, except selecting Keep for all packages and thus doing nothing more than I select it manually to do? What does it different than changing all unwanted updates to Keep manually in the package list? If you ask me, Setup is long overdue for a complete replacement. It don't have so many things other package managers allow, that I don't even know, where to start. Meta dependencies? Suggestions? Virtual packages? Indeed, no objection here. But still I find it strange that Cur selects 2.0.4, while it is not selectable manually in the New column. Select pending list and remove checkboxes from binary packages you don't want to install. Sure, that is what I described. But I don't update the packages often, as I always have open a dozen bashes or so, and don't want to close all because of update of files in use. So there are a lot of packages to deselect. But --packages ftw. :-) P.S. Please don't https://cygwin.com/acronyms/#TOFU Sorry Regards Björn -- 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: setup.exe handles same packages in multiple mirrors badly
Greetings, Corinna Vinschen! If you ask me, Setup is long overdue for a complete replacement. It don't have so many things other package managers allow, that I don't even know, where to start. Meta dependencies? Suggestions? Virtual packages? The problem is not that we don't know this, the problem is, as so often, that we only have a handful of active developers at all, and nobody having the time nor inclination to work on setup to keep it ahead of time. Apology again. :( At 5am brain want only one thing. And it's not writhing comprehensive posts. I was intent on clarifying your point, but brain said BED! and legs followed. Setup was a wonderful idea, way back when it has been created, but the vintage charm of its Y2K roots are a bit depressing these days. So, if anybody wants to take a stab at setup and revamp it, feel free. The only requirements are, it should still be able to utilize the setup.ini file created on cygwin.com, it should still be able to work the mirror list provided by cygwin.com, and it should still provide a GUI and a command line. Everything else is open for renewal. You might add should be native application and should compile with Cygwin provided toolchain. Else it'll be an unbearable nightmare to support. -- WBR, Andrey Repin (anrdae...@yandex.ru) 26.08.2014, 13:49 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: setup.exe handles same packages in multiple mirrors badly
On Aug 26 13:53, Andrey Repin wrote: So, if anybody wants to take a stab at setup and revamp it, feel free. The only requirements are, it should still be able to utilize the setup.ini file created on cygwin.com, it should still be able to work the mirror list provided by cygwin.com, and it should still provide a GUI and a command line. Everything else is open for renewal. You might add should be native application and should compile with Cygwin provided toolchain. Else it'll be an unbearable nightmare to support. Doesn't that go without saying? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpOjipnSz34p.pgp Description: PGP signature
About cygstart in Cygwin64
When I had WinXP32 and Cygwin32, I defined an alias (in .bashrc) like this alias cygstart='TEMP=/home/$USER/Temp cygstart' where /home/$USER/Temp was a symlink to the user native Temp directory (/cygdrive/c/Documents and Setting/Local/Temp, if I remember..) The reasons for that alias with TEMP=/home.. in front, were that, opening documents with Windows native applications (for example, a PDF with AR), all temporary files that those applications created were saved in the Windows native Temp directory. And all this worked.. Now with Win7U and Cygwin64 I defined a similar alias, being /home/$USER/Temp the symlink /home/$USER/Temp -- /cygdrive/c/$USER/AppData/Local/Temp In this case, all temporary files created by Windows native applications, started with cygstart, go in /tmp Cygwin directory.., i.e. the definition TEMP=/home/$USER/Temp in front of cygstart command is ignored.. This is a minor issue but I wonder if there is a way to avoid it. TIA, Angelo. -- 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: setup.exe handles same packages in multiple mirrors badly
Greetings, Corinna Vinschen! So, if anybody wants to take a stab at setup and revamp it, feel free. The only requirements are, it should still be able to utilize the setup.ini file created on cygwin.com, it should still be able to work the mirror list provided by cygwin.com, and it should still provide a GUI and a command line. Everything else is open for renewal. You might add should be native application and should compile with Cygwin provided toolchain. Else it'll be an unbearable nightmare to support. Doesn't that go without saying? Just for completeness. Not everyone is familiar with intricacies of Cygwin's setup. -- WBR, Andrey Repin (anrdae...@yandex.ru) 26.08.2014, 14:48 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: About cygstart in Cygwin64
Angelo Graziosi angelo.graziosi at alice.it writes: In this case, all temporary files created by Windows native applications, started with cygstart, go in /tmp Cygwin directory.., i.e. the definition TEMP=/home/$USER/Temp in front of cygstart command is ignored.. You should check if somehow you've also set TMP or TMPDIR environment variables in the environment. This is a minor issue but I wonder if there is a way to avoid it. How about you simply create a user bind mount that points to where you want it to be and leave TEMP alone? 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: Why does df fail to stat CIFS shares?
On Aug 26 09:14, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: (which seems likely in this case) I would need your cooperation to run debugging sessions to be able to come up with a fix. Is that ok? Sorry, can't do that. Then you have to build your own Cygwin DLL for testing. 28 2542465 [main] df 15880 statvfs: (/home/gratz, 0x22A5E0), file_attributes 48 1404 2543869 [main] df 15880 fhandler_disk_file::fstatvfs: 0xC00D = NtQueryVolumeInformationFile(\??\H:\GNU, FileFsFullSizeInformation) The call to NtQueryVolumeInformationFile() in fhandler_disk_file::fstatvfs() in fhandler_disk_file.cc (line 737ff), fails with STATUS_INVALID_PARAMETER. This is a NetApp bug, but we may be able to workaround it. Given the lack of complex parameters, and given that, as you claim, this occurs on 32 and 64 bit, I can see only one (well, two) potential culprits, the NtOpenFile calls at lines 751 and 761. One of the following is the problem: - The Netapp drive chokes on the FILE_OPEN_FOR_BACKUP_INTENT open flags. This is *very* unlikely, though, given that it's a required flag to open a directory. Nevertheless, try to set it to 0 just for testing. - Or, Netapp expects the call to run in SYNCHRONIZE mode. To test that, set the open mode to READ_CONTROL|SYNCHRONIZE. This also requires to set the open flags to FILE_OPEN_FOR_BACKUP_INTENT|FILE_SYNCHRONOUS_IO_NONALERT - Or, the READ_CONTROL open mode isn't enough for Netapp. Try to open the file with GENERIC_READ for a start, and then, if that works, try to reduce the flags to something containing READ_CONTROL, FILE_OPEN_DATA, and FILE_OPEN_ATTRIBUTES. Try in combination with SYNCHRONIZE and FILE_SYNCHRONOUS_IO_NONALERT. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp0YYOEAv6A9.pgp Description: PGP signature
Re: Update to latest cygwin creates crashes in dlclose()
On Aug 25 10:30, Cary R. wrote: On Aug 22 16:45, Cary R. wrote: I upgraded to the latest cygwin earlier today (it has probably been a month or more since I last updated) and now a program that has been working is crashing (segfault) when calling dlclose(). dlopen() and calling a function in the DLL still works just fine. An older version of the program still works correctly so it's not just simply calling dlclose() but something more context dependent. Is you applications written in C++? Yes the primary application is C++. The DLL is mixed C and C++. Does recompiling with the latest gcc 4.8.3-3 fix the issue? make distclean, a reconfigure and then a complete recompile was the first thing I tried when I noticed the failure and that did not fix the crash. Typically a SEGV creates a stackdump file. Can you show us? No stackdump file is being created. If I remove the call to dlclose() the application does not SEGV and appears to run correctly. Here is the output from gdb: ~/src/verilog/iverilog-push/iverilog/vvp gdb ./vvp-dev.exe [...] (gdb) run -M../vpi ../../iverilog/vvp/examples/hello.vvp Starting program: /cygdrive/c/src/verilog/iverilog-push/iverilog/vvp/vvp-dev.exe -M../vpi ../../iverilog/vvp/examples/hello.vvp [New Thread 4152.0x78c] [New Thread 4152.0x1254] Warning: vvp input file may not be correct version! Hello, World. Program received signal SIGSEGV, Segmentation fault. 0x6314c658 in ?? () (gdb) bt #0 0x6314c658 in ?? () Hmm, YA case of __gcc_deregister_frame crashing? For a start you could check in which DLL this crash occurs. Call `rebase -si' and check in which DLL this address is on your system. I hazard the guess it's going to be /bin/cyggcc_s-1.dll... Last but not least, do you have a simple testcase to reproduce the issue? I do not have a simple test case yet. Since this is an open source application you could compile it to observe the behavior, but I was planning to look into this more based on any feedback and my available free time this week. Ok, I'll look into other stuff for now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpaxwRUPFfXm.pgp Description: PGP signature
Re: Why does df fail to stat CIFS shares?
Corinna Vinschen corinna-cygwin at cygwin.com writes: Then you have to build your own Cygwin DLL for testing. I've just set up for a build and ran into this (with the snapshot sources from 2014-08-19 since these were the ones I had at hand): ccwrap -g -O2 -O3 -mtune=core2 -march=core2 -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -fomit-frame-pointer -Werror -fmerge-constants -ftracer -mcmodel=small -c -o regcomp.o ../../.././winsup/cygwin/regex/regcomp.c ../../.././winsup/cygwin/regex/regcomp.c: In function ‘p_bracket’: ../../.././winsup/cygwin/regex/regcomp.c:1249:12: error: ‘s’ may be used uninitialized in this function [-Werror=maybe-uninitialized] wint_t i, s, n; So I configured again with --disable-werror, lets see if that produces a usable DLL now. 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: Why does df fail to stat CIFS shares?
On Aug 26 15:00, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: Then you have to build your own Cygwin DLL for testing. I've just set up for a build and ran into this (with the snapshot sources from 2014-08-19 since these were the ones I had at hand): ccwrap -g -O2 -O3 -mtune=core2 -march=core2 -Wall -Wstrict-aliasing ^^^ Huh? Did you specify -O3 explicitely? Don't. -O2 is default and sufficient. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4UyQHIxXHY.pgp Description: PGP signature
Re: Why does df fail to stat CIFS shares?
Corinna Vinschen writes: I've just set up for a build and ran into this (with the snapshot sources from 2014-08-19 since these were the ones I had at hand): ccwrap -g -O2 -O3 -mtune=core2 -march=core2 -Wall -Wstrict-aliasing ^^^ Huh? Did you specify -O3 explicitely? Don't. -O2 is default and sufficient. I think it has picked up some settings from the environment. I will investigate tomorrow, I don't use this machine for builds normally. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: About cygstart in Cygwin64
On 8/26/2014 3:24 AM, Angelo Graziosi wrote: When I had WinXP32 and Cygwin32, I defined an alias (in .bashrc) like this alias cygstart='TEMP=/home/$USER/Temp cygstart' where /home/$USER/Temp was a symlink to the user native Temp directory (/cygdrive/c/Documents and Setting/Local/Temp, if I remember..) Here's what I do - use Cygwin's tmp (i.e. /tmp in Cygwin and C:\Cygwin\tmp for Windows). Then change the TEMP and TMP environment variables to point to C:\Cygwin\tmp. Then simply think of temp as /tmp. The reasons for that alias with TEMP=/home.. in front, were that, opening documents with Windows native applications (for example, a PDF with AR), all temporary files that those applications created were saved in the Windows native Temp directory. And all this worked.. Now with Win7U and Cygwin64 I defined a similar alias, being /home/$USER/Temp the symlink /home/$USER/Temp -- /cygdrive/c/$USER/AppData/Local/Temp In this case, all temporary files created by Windows native applications, started with cygstart, go in /tmp Cygwin directory.., i.e. the definition TEMP=/home/$USER/Temp in front of cygstart command is ignored.. This is a minor issue but I wonder if there is a way to avoid it. Any self respecting Windows app should honor either $TMP or $TEMP. Non self respecting Windows apps should be uninstalled ;-) -- Andrew DeFaria http://defaria.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: (call-process ...) hangs in emacs
Ken Brown writes: It looks like my idea is going to work, but it needs testing to make sure I've implemented it correctly. If anyone is willing to test it, you can download emacs-24.3.93-2 from my personal Cygwin repository: http://sanibeltranquility.com/cygwin/ Instructions can be found at that URL. I've switched to this version today. I've noticed that two bugs are still present at least in the emacs-w32 version: 1) When showing the Windows desktop with Win-D and then restoring it (including Emacs) with Win-D again, the cursor becomes a hollow rectangle that doesn't blink. To get the normal cursor behaviour back you have to minimize and restore the Emacs window in the normal way. 2) Files that have no POSIX permissions (filemode ) and where access is granted via ACL only get always opened as read-only and you have to C-x C-q them before saving. It appears that this is Cygwin specific since on Linux the same version copes with that situation correctly (however, the mask bits in the ACL get displayed in the group portion of the file mode, which I've never seen happen on Cygwin, so this may be something that Cygwin needs to do -- maybe that'd even solve the problems that Perl has in the same situation). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: connect() hangs on a listen()ing AF_UNIX socket
Corinna Vinschen wrote:
On Aug 22 20:32, Christian Franke wrote:
Corinna Vinschen wrote:
Another potential solution might be to defer the AF_UNIX handshake to
the first send/recv:
Whatever the peers do, there is a certain protocol used. That means,
there's an implicit understanding who's going to do the first send and
who's doing the first recv. So, after connect/accept, both sides of the
sockets go into connected_but_handshake_missing mode. On the first
send/recv, the handshake gets started and if it fails, send/recv
return ECONNRESET.
Is an actual handshake really required? It would possibly be sufficient that
each peer sends its secret+credential and then expects a correct
secret+credential from the other peer before sending anything.
After actual connect()/accept():
send our secret+cred (should not block due to TCP queuing).
So both peers send their credentials...
if (! nonblocking recv peer secret+cred)
set_state(connected_but_secret_missing)
else
set_state(connected)
This will almost always result in connected_but_secret_missing. It's
probably ok to drop the recv attempt here entirely.
Agree.
Before actual send()/recv()/getpeerid():
if (state == connected_but_secret_missing) {
if (! recv peer secret+cred)
abort_connection(ECONNRESET)
else
set_state(connected)
}
Sounds like a nice idea. We should try that. I'm just not sure how
much time I have left to work on this before my vaca next month. Do you
have fun to look into that? We have waited so long for postfix, I guess
a couple more weeks won't really hurt.
OK, will try that
Postfix apparently pushes Cygwin to its limits. With a test cygwin1.dll
where the secret+cred exchange is fully disabled, postfix starts up but
queuing of mail fails.
This is because fchmod() is called on a file rename()d after open():
fd = open(tempfile, ., 0600);
// use fd's inode number and current time to create unique queuefile.
rename(tempfile, queuefile);
write(fd, SOME MAIL, .);
fchmod(fd, 0700); // fails with ENOENT on Cygwin (because it does a
chmod(tempfile,.)?)
close(fd);
A workaround using chmod(queuefile, 0700) helped here. Then smtp
client, smtpd server (direct or via smarthost), sendmail emulation and
local delivery to maildir works. Running as service with uid/gid
switching is not tested yet.
It will likely take some time to look into all these details before
first ITP.
(Therefore let's forget the cygcheck -m patch for now :-).
Christian
--
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: connect() hangs on a listen()ing AF_UNIX socket
On Aug 26 21:03, Christian Franke wrote: Corinna Vinschen wrote: Sounds like a nice idea. We should try that. I'm just not sure how much time I have left to work on this before my vaca next month. Do you have fun to look into that? We have waited so long for postfix, I guess a couple more weeks won't really hurt. OK, will try that Cool! Don't hesitate to discuss implementation details on the cygwin-developers list. Postfix apparently pushes Cygwin to its limits. With a test cygwin1.dll where the secret+cred exchange is fully disabled, postfix starts up but queuing of mail fails. This is because fchmod() is called on a file rename()d after open(): fd = open(tempfile, ., 0600); // use fd's inode number and current time to create unique queuefile. rename(tempfile, queuefile); write(fd, SOME MAIL, .); fchmod(fd, 0700); // fails with ENOENT on Cygwin (because it does a chmod(tempfile,.)?) close(fd); I fixed that in CVS (and I'm just generating a snapshot). The problem was that the functions reading and writing security descriptors didn't use the special reopen by handle semantics of the NtOpenFile call if a reopen was necessary. Rather they just tried to open the file by name again, just with different open flags. I fixed that, as well as another occurence of the same problem when trying to read and write extended attributes. This won't work on filesystems which don't support reopen semantics, which is Netapp and NWFS. I have an idea how to workaround that for these FSes, but that's not high priority. A workaround using chmod(queuefile, 0700) helped here. Then smtp client, smtpd server (direct or via smarthost), sendmail emulation and local delivery to maildir works. Running as service with uid/gid switching is not tested yet. It will likely take some time to look into all these details before first ITP. (Therefore let's forget the cygcheck -m patch for now :-). Ok, no worries there :) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpxSQHb0eCSq.pgp Description: PGP signature
Re: (call-process ...) hangs in emacs
On 8/26/2014 2:55 PM, Achim Gratz wrote: Ken Brown writes: It looks like my idea is going to work, but it needs testing to make sure I've implemented it correctly. If anyone is willing to test it, you can download emacs-24.3.93-2 from my personal Cygwin repository: http://sanibeltranquility.com/cygwin/ Instructions can be found at that URL. I've switched to this version today. I've noticed that two bugs are still present at least in the emacs-w32 version: 1) When showing the Windows desktop with Win-D and then restoring it (including Emacs) with Win-D again, the cursor becomes a hollow rectangle that doesn't blink. To get the normal cursor behaviour back you have to minimize and restore the Emacs window in the normal way. This one has nothing to do with emacs. I see the same thing in mintty, with just a shell prompt (bash in my case). 2) Files that have no POSIX permissions (filemode ) and where access is granted via ACL only get always opened as read-only and you have to C-x C-q them before saving. It appears that this is Cygwin specific since on Linux the same version copes with that situation correctly (however, the mask bits in the ACL get displayed in the group portion of the file mode, which I've never seen happen on Cygwin, so this may be something that Cygwin needs to do -- maybe that'd even solve the problems that Perl has in the same situation). AFAICT, emacs decides whether the file is writable via the system call faccessat. (See the function 'check_writable' in src/fileio.c.) This is not Cygwin specific. So faccessat must be returning failure in the scenario you described. I don't know if that's a Cygwin bug or not. BTW, emacs on Cygwin doesn't directly check ACLs, because the relevant configure test fails. That would explain the ACL display you see on Linux but not on Cygwin. But I think this is a separate matter, not related to the bug you're reporting. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows 7 sshd can only login as cyg_server
On 8/25/14 11:49 AM, Larry Hall (Cygwin) wrote:
On 08/25/2014 07:00 AM, Corinna Vinschen wrote:
On Aug 25 12:51, Corinna Vinschen wrote:
On Aug 22 17:24, Larry Hall (Cygwin) wrote:
On 08/22/2014 04:44 PM, Corinna Vinschen wrote:
snip
I solved it:
It turned out, that my Windows domain policy was updating local policies
in a way, that the local cyg_server account lost his group membership to
the group 'Administrators' every time I log into my Windows 7.
I have to fix that every time before I start sshd.
I wrote a little python script that does the whole thing. In case
someone wants to reuse it, enjoy:
#!/usr/bin/python
# -*- coding utf-8 -*-
import win32net
import win32serviceutil
user = cyg_server
group = Administrators
# make sure sshd user is in admin group
data = [ {domainandname : user} ]
mem, tot, res = win32net.NetLocalGroupGetMembers(None, group, 1)
inGroup = False
for item in mem:
if (item['name']) == user:
inGroup = True
break
if not inGroup:
win32net.NetLocalGroupAddMembers(None, Administrators, 3, data)
# restart sshd
win32serviceutil.RestartService(sshd)
--
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
Updated: procps-3.2.8-3
I updated the 32 bit procps package to 3.2.8-4. This fixes my accidental upload of a 64 bit 3.2.8-3 package into the 32 bit release. Sorry, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
