Re: problem with sshd
On Thu, Dec 23, 2010 at 11:59 AM, Thorsten Kampe thors...@thorstenkampe.de wrote: I searched and found only one message describing this problem which was left without answer... http://search.gmane.org/?query=zombie%20ssh% 20bashgroup=gmane.os.cygwin Thanks, a lot of similar bugreports since 2007 and no single solution. -- 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: problem with sshd
On Wed, Dec 22, 2010 at 12:41 PM, Thorsten Kampe thors...@thorstenkampe.de wrote: * Vasya Pupkin (Wed, 22 Dec 2010 09:26:29 +0300) I have a problem running cygwin sshd. I often end up with a lot of bash processes running and eating memory while there are no single active ssh session. It happens when either connection lost or user closes connection without logging out, sshd process dies but bash remains in memory forever. Is it possible to prevent this? In all real unix environments this never happen, bash always dies when parent sshd exits. That is (or was) an old problem as far as I remember. Search the mailing list archives to see if it is supposed to be fixed or a workaround is available. Maybe someone else here remembers more than me... I searched and found only one message describing this problem which was left without answer... -- 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: problem with sshd
On Wed, Dec 22, 2010 at 9:50 PM, David Sastre d.sastre.med...@gmail.com wrote: I have a problem running cygwin sshd. I often end up with a lot of bash processes running and eating memory while there are no single active ssh session. It happens when either connection lost or user closes connection without logging out, sshd process dies but bash remains in memory forever. Is it possible to prevent this? In all real unix environments this never happen, bash always dies when parent sshd exits. You might want to enable TCPKeepAlive. It could, at a very least, prevent disconnections without explicit user interaction. It's enabled. When sshd not receiving keepalives (network issue or user closed terminal), it dies (which is good) and leaves bash process running forever (which is not good). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
problem with sshd
I have a problem running cygwin sshd. I often end up with a lot of bash processes running and eating memory while there are no single active ssh session. It happens when either connection lost or user closes connection without logging out, sshd process dies but bash remains in memory forever. Is it possible to prevent this? In all real unix environments this never happen, bash always dies when parent sshd exits. -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
If you read again very carefully, you will see that I modified permissions AFTER I noticed they were messed up. Ok? In my case, these additional permissions were allowing everyone to modify files. Not harmful at all, indeed. I do not remember all the details, I remember these permissions were everywhere. So I just replaced everything with proper permissions and disabled acl support in cygwin. The only problem was setup.exe but now I compiled it with a modification and this last problem gone. I understand that I do not have all the details required for a bug report. And it wasn't an attempt to report a bug. I was asked why I care about permissions, so I answered. Anyway, the problem is solved now, I also submitted an easy patch to setup.exe source for everyone who want to get rid of this problem as well. If I ever get into a problem with permissions again, I will try to make a proper bug report instead of just fixing permissions. On Thu, Sep 2, 2010 at 6:28 PM, Jeremy Bopp jer...@bopp.net wrote: On 9/2/2010 12:49 AM, Vasya Pupkin wrote: No, it wasn't a mess of my own making. I did not ever touch permissions, and it was a clean install. I don't know where these permissions came from, but ls -l displayed something like that for most files: I read Andy's comment to mean that the mess of your own making is the result of you changing the permissions, not the existing permissions as left by setup.exe. You made the mess (or correction as you see it) and are now fighting with setup.exe to maintain it. drwxr-xr-x+ 1 user group 0 2010-09-02 09:32 tests This + sign after permissions string indicated non-cygwin permissions which was impossible to remove using cygwin's chmod. And since permissions are not inherited, it was not possible to mass remove them using windows either. So, I just removed all permissions and forced their inheritance. That solved all problems, until I updated installation using setup.exe. The + indicates that there are further permissions specified as ACLs for which the getfacl and setfacl commands should be used to view and manipulate, respectively. You would see the same behavior from ls on a Linux system which had ACL support and extra ACLs applied to a similar file or directory. There, too, chmod would not be able to modify those ACLs. What your example does not indicate is that anything unintentional happened with the application of permissions on that example directory. Nor does it indicate that the given permissions are in any way harmful to the maintenance of your system or the use of the files and directories in question. Where was that directory located? Did you create it, or did setup.exe create it? What problems do those permissions cause? Believe me or not, but I really did not touch any permissions until I noticed that strange behaviour. And I am the only administrator. Machine is not a part of any domains. So, unless it's a kind of black magic, there was (and maybe still is) some issue with permissions in cygwin. That is why I don't want to use them. I'm sure the Cygwin developers would be more than willing to patch any defect surrounding the incorrect application of permissions to files which is the result of Cygwin itself or setup.exe. Unfortunately, you have not demonstrated any such erroneous behavior yet. It seems more likely that you have a small misunderstanding about how the permissions you see work and how they are represented under Cygwin. Have you read the section of the user guide which discusses permissions under Cygwin? Perhaps, you have found a genuine defect. If so, you need to provide more data so that someone else can reproduce the problem. You could start by installing another instance of Cygwin into a fresh directory (this won't affect your primary installation) and then demonstrate the specific files that have faulty permissions and explain how those permissions will lead to further problems. With luck, someone will be able to explain why things are the way you see them such that you are comfortable accepting how Cygwin does things. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On Thu, Sep 2, 2010 at 8:25 PM, Jeremy Bopp jer...@bopp.net wrote: Your answer was simply an assertion that there possibly was and may still be something wrong with the permissions handling under Cygwin, but that you also haven't confirmed that recently. The details really would be helpful and likely necessary if you would like to have your patch accepted by the maintainers of setup.exe. No, my patch can't be accepted as it removes permissions handling completely. It wasn't me who started the thread and I believe, my patch can be of interest for anyone else who will search for a solution for this specific problem. Anyway, I don't see how an option to switch off permissions handling by setup.exe can harm while there is similar functionality in cygwin itself. My very limited understanding of C is not enough to do this, and I never worked with GUI applications. But I will see if it can be done via command line switch and if I succeed, I will submit a proper patch. -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On Fri, Sep 3, 2010 at 12:49 AM, Andy Koppe andy.ko...@gmail.com wrote: How did you find the problematic permissions? By looking at the security tab of the file properties? Did you confirm that users really were able to modify files they weren't supposed to? Could the offending privileges have been inherited from the directory Cygwin was installed in? If only I could remember all the details. I didn't have much time to figure out what happened. Easy solution for me was to disable acl in cygwin, which I did, and was happy until I used setup.exe and found out it destroyed my permissions. -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
There we go, a proper patch. It adds two command line parameters: -f --no-acl-files -F --no-acl-dirs I could not figure if that's possible to share single variable between two source files, so I just used two variables. At least it works as intended and covers every situation. On Thu, Sep 2, 2010 at 9:12 AM, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: On Thu, Sep 02, 2010 at 06:08:37AM +0400, Vasya Pupkin wrote: Because I prefer to keep things under control. And I don't think it will require a huge amount of work to disable working with permissions in setup.exe with command line switch. Well, go ahead then. What are you waiting for? Send us a patch. cgf -- 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 filemanip.cc.diff Description: Binary data mkdir.cc.diff 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: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
I am facing similar issue and this is actually why I stopped using Cygwin. There is no way to tell setup.exe to stop destroying permissions. And noone seem to care about it. On Wed, Sep 1, 2010 at 12:00 PM, Harie Ram hari.ra...@gmail.com wrote: -- Forwarded message -- From: Harie Ram hari.ra...@gmail.com Date: Tue, Aug 31, 2010 at 8:11 PM Subject: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7 To: cygwin-i...@cygwin.com Hi , I am currently packaging Cygwin 1.7 i.e. bundling all the files into an msi and installing it. The requirement is : install only the basic cygwin packages. Provide permissions to the Cygwin users so that they can install the packages that they require later. The issue that I am currently facing is : the modify permissions given to the INSTALLDIR C:\Cygwin using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. I have tried editing the /etc/fstab file with the noacl value. Still its not working. The content of my /etc/fstab file is as follows: C:/cygwin/bin /usr/bin ntfs binary,auto,noacl 0 0 C:/cygwin/lib /usr/lib ntfs binary,auto,noacl 0 0 C:/cygwin /cygwin ntfs override,binary,auto,noacl 0 0 I am aware of the fact that CYGWIN=nontsec environment variable is obsolete for this version. Please help. Thanks, HRS -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Cygwin uses NTFS ACLs to imitate POSIX style permissions. It can also be configured to not touch ACL's at all, but setup program ignores that and messes up permissions every time something is installed/updated. On Wed, Sep 1, 2010 at 4:49 PM, Rolf Campbell rcampbell-cyg...@dragonwaveinc.com wrote: On 2010-09-01 04:00, Harie Ram wrote: The issue that I am currently facing is : the modify permissions given to the INSTALLDIR C:\Cygwin using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. AFAIK, Cygwin uses POSIX style file permissions, which do not support any type of inherited file permissions. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Nothing can overcome thins until setup.exe is modified to support noacl option in /etc/fstab or get a similar comman line parameter or even a checkbox. On Wed, Sep 1, 2010 at 6:00 PM, Harie Ram hari.ra...@gmail.com wrote: Do creating any entries in /etc/passwd or /etc/group or /etc/fstab files can overcome this... Thanks On Wed, Sep 1, 2010 at 7:21 PM, Vasya Pupkin cyg...@bsrealm.net wrote: Cygwin uses NTFS ACLs to imitate POSIX style permissions. It can also be configured to not touch ACL's at all, but setup program ignores that and messes up permissions every time something is installed/updated. On Wed, Sep 1, 2010 at 4:49 PM, Rolf Campbell rcampbell-cyg...@dragonwaveinc.com wrote: On 2010-09-01 04:00, Harie Ram wrote: The issue that I am currently facing is : the modify permissions given to the INSTALLDIR C:\Cygwin using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. AFAIK, Cygwin uses POSIX style file permissions, which do not support any type of inherited file permissions. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Because I prefer to keep things under control. And I don't think it will require a huge amount of work to disable working with permissions in setup.exe with command line switch. I started to worry about it because cygwin failed so much with permissions, having both cygwin-specific and inherited ones (copied) at the same time, resulting in complete mess. A non-privileged user could modify cygwin configuration files in /etc and it was not possible to do something about it. That is when I decided to control permissions myself, but cygwin setup overwrites permissions on every install, including files in /etc, messing up everything. On Thu, Sep 2, 2010 at 12:18 AM, Andy Koppe andy.ko...@gmail.com wrote: On 1 September 2010 15:18, Vasya Pupkin wrote: Do creating any entries in /etc/passwd or /etc/group or /etc/fstab files can overcome this... Nothing can overcome thins until setup.exe is modified to support noacl option in /etc/fstab or get a similar comman line parameter or even a checkbox. Reading /etc/fstab wouldn't work for the initial install. All these possibilities require a substantial amount of (voluntary) work, yet so far the only reason you've given for it was that you don't like how cygwin works with NTFS permissions and therefore it is disabled through /etc/fstab. It shouldn't surprise you that that doesn't put it high on anyone's list of priorities. So why do you care about permissions on files that come with setup.exe packages? Setup.exe won't touch /home or anything outside the Cygwin install. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
can't compile setup.exe
I'm trying to compile setup.exe from source code I got from CVS. For some reason, I am getting an error: propsheet.cc: In member function `bool PropSheet::SetActivePage(int)': propsheet.cc:444: error: expected id-expression before '::' token propsheet.cc:444: error: expected `)' before '::' token propsheet.cc:444: error: expected `;' before '::' token propsheet.cc:444: error: expected `;' before ')' token propsheet.cc: In member function `bool PropSheet::SetActivePageByID(int)': propsheet.cc:452: error: expected id-expression before '::' token propsheet.cc:452: error: expected `)' before '::' token propsheet.cc:452: error: expected `;' before '::' token propsheet.cc:452: error: expected `;' before ')' token propsheet.cc: In member function `void PropSheet::SetButtons(DWORD)': propsheet.cc:459: error: expected id-expression before '::' token propsheet.cc:459: error: expected `;' before '::' token propsheet.cc: In member function `void PropSheet::PressButton(int)': propsheet.cc:465: error: expected id-expression before '::' token propsheet.cc:465: error: expected `;' before '::' token make[2]: *** [propsheet.o] Error 1 I did not touch this file. I installed all required packages and followed instruction in README file. -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Will do as soon as I get this thing to at least compile. Actually, since there is no abstract layer for nt_wfopen(), all calls to this function have to be modified. Alternatively, the function can be modified to ignore perms parameter and alternative version of setup.exe can be compiled then. That is the way I chose, but there is some problem in another file that I cannot fix myself. You can see my previous message about that. Regardless, this is the simple patch: === --- filemanip.cc2010-03-01 18:18:39.0 +0300 +++ filemanip.cc.new2010-09-02 09:33:05.094182900 +0400 @@ -433,8 +433,10 @@ IO_STATUS_BLOCK io; UNICODE_STRING uname; OBJECT_ATTRIBUTES attr; + /* SECURITY_DESCRIPTOR sd; acl_t acl; + */ const char *c; ULONG access, disp; int oflags = 0; @@ -489,11 +491,14 @@ PWCHAR wname = (PWCHAR) wpath; wname[1] = L'?'; RtlInitUnicodeString (uname, wname); + /* InitializeObjectAttributes (attr, uname, OBJ_CASE_INSENSITIVE, NULL, disp == FILE_OPEN || perms == 0 ? NULL : nt_sec.GetPosixPerms (, NULL, NULL, perms, sd, acl)); + */ + InitializeObjectAttributes (attr, uname, OBJ_CASE_INSENSITIVE, NULL, NULL); status = NtCreateFile (h, access | SYNCHRONIZE, attr, io, NULL, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_VALID_FLAGS, disp, FILE_OPEN_FOR_BACKUP_INTENT === Instead of commenting code, defines can be used to allow choosing required behaviour at compile time. On Thu, Sep 2, 2010 at 9:12 AM, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: On Thu, Sep 02, 2010 at 06:08:37AM +0400, Vasya Pupkin wrote: Because I prefer to keep things under control. And I don't think it will require a huge amount of work to disable working with permissions in setup.exe with command line switch. Well, go ahead then. What are you waiting for? Send us a patch. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
No, it wasn't a mess of my own making. I did not ever touch permissions, and it was a clean install. I don't know where these permissions came from, but ls -l displayed something like that for most files: drwxr-xr-x+ 1 user group 0 2010-09-02 09:32 tests This + sign after permissions string indicated non-cygwin permissions which was impossible to remove using cygwin's chmod. And since permissions are not inherited, it was not possible to mass remove them using windows either. So, I just removed all permissions and forced their inheritance. That solved all problems, until I updated installation using setup.exe. Believe me or not, but I really did not touch any permissions until I noticed that strange behaviour. And I am the only administrator. Machine is not a part of any domains. So, unless it's a kind of black magic, there was (and maybe still is) some issue with permissions in cygwin. That is why I don't want to use them. On Thu, Sep 2, 2010 at 9:10 AM, Andy Koppe andy.ko...@gmail.com wrote: On 2 September 2010 03:08, Vasya Pupkin wrote: Because I prefer to keep things under control Oh $DEITY. And I don't think it will require a huge amount of work to disable working with permissions in setup.exe with command line switch. I started to worry about it because cygwin failed so much with permissions, having both cygwin-specific and inherited ones (copied) at the same time, resulting in complete mess. That appears to be a mess of your own making. Otherwise, concrete bug reports please. The OP's complaint here was that permissions aren't inherited, so I've got no idea what you're on about. A non-privileged user could modify cygwin configuration files in /etc and it was not possible to do something about it. Well, I don't know what you did, but I install Cygwin as administrator and work as an ordinary user, and no, I can't modify anything in /etc. And that's no accident of course, because a lot of work has gone into mapping POSIX permissions to NTFS permissions in a sensible way. Andy ps: Please don't top-post. http://www.cygwin.com/acronyms/#TOFU -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.6 due soon
I'm just wondering, will setup.exe honor new mount options, or it will still mess up NTFS permissions? On Fri, Jun 25, 2010 at 4:45 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: A lot of changes and fixes have been made in Cygwin since 1.7.5 has been released, so we're looking forward to release Cygwin 1.7.6 soon. Please test the latest developer snapshots at http://cygwin.com/snapshots/ which should have Release Candidate quality. Please report bugs to the cygwin at cygwin dot com mailing list. Please follow the guidelines at http://cygwin.com/problems.html Be aware that we're mainly focusing on regressions from 1.7.5. What's new: - Add new mount options dos and ihash to allow overriding Cygwin default behaviour on broken filesystems not recognized by Cygwin. - A new mechanism is used to propagate pty handles safely to other processes, which does not require to use Cygserver. - Pass on coresize settings made with setrlimit(2). This allows shells to disable creating stackdump files in child processes via `ulimit -c 0' in bash or `limit coredumpsize 0' in tcsh. - Locale categories contain all localization strings additionally as wide-char strings. locale(1) prints these values just as on Linux. nl_langinfo(3) allows to fetch them. Fixes: - Fix problem where pseudo-relocs were getting applied twice, resulting in a crash. - Fix a crash when accessing /proc/registry* - Avoid that connect on a not yet established AF_LOCAL/AF_UNIX socket misinterprets the socket file as non-socket. - Fix stdin/out/err handle permissions when called from a non-Cygwin process. - Fix codeset problem in internal handling of process name. - Fix abbreviated month names for japanese and korean locale. - Fix calls to gettimeofday after call to settimeofday. - Fix REG_MULTI_SZ handling in /proc/registry* - Honor cygwin username even if it only differs by case from Windows username. - Fix potential memory leak when accessing // or //server directories. - Fix using a wrong handle when cehcking for files inaccessible to current user. - Fix erroneous handling of devices in path checking. - Fix potential crash in exec(2) if parent uses file locking. Other changes: - Change the way a process is made process group leader in case we're started from a non-Cygwin process. This isn't foolproof and may need more work. - Workaround BLODA problem in rename(2) which otherwise results in annoying errors. - Improve error output in strace. - Add more workarounds for broken filesystems which either don't grok reopening a file by handle (NWFS) or which are not capable of handling filenames with leading spaces or trailing dots or spaces (NWFS, Netapp). - Don't try to evaluate reparse points (junctions) on remote filesystems as symlinks. - Improve performance of stat and a few other functions. ls(1) should be up to 30% faster on some drives. Corinna To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from 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. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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 -- 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 messing up ntfs permissions
So, I guess there is now way to tell setup.exe to stop messing up NTFS permissions currently. May I ask to add such feature then? -- 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
setup messing up ntfs permissions
Is there any way to stop setup program from messing up NTFS permissions? I don't like how cygwin works with NTFS permissions and therefore it is disabled through /etc/fstab, but setup ignores it and keeps destroying inherited permissions and replacing them with custom ones every time it installs something. -- 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
