From earnie_boyd@yahoo.com Tue Jun 1 05:13:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Tue, 01 Jun 1999 05:13:00 -0000 Subject: ntsec documentation, 2nd try Message-ID: <19990601121341.20549.rocketmail@web108.yahoomail.com> --- Corinna Vinschen wrote: > Hi! > > I have changed this and that in the documentation. Some errors, > strange English language, etc. > Please read it and send opinions, error reports, patches to me. > > Regards, > Corinna > > -- > new mail address: > mailto:corinna@vinschen.de > NTSEC Documentation > =================== > > The design goal of the ntsec patch was, to get a more UNIX like > permission structure, based upon the security features of Windows NT. > To describe the changes, I will give a short overview of NT security > in chapter one. > Chapter two discusses the change in ntsec, related to privileges on > processes. > Chapter three shows the UNIX like setting of file permissions. > > The setting of UNIX like object permissions is controlled by the new > CYGWIN variable setting `[no]ntsec'. > > On NT, ntsec is now turned on by default. > -8<- Corinna, I think you've done an excellent job at explaining this. In order to advert questions about how to use the functions or where to get examples, I suggest you give examples of use or pointers to where to find the examples. Thank-you for your contributions. === YAWIA,
Earnie Boyd
Newbies Click Here _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From corinna@vinschen.de Tue Jun 1 05:31:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Tue, 01 Jun 1999 05:31:00 -0000 Subject: mkpasswd and mkgroup patch, ntsec documentation, 3rd try References: <19990529184049.C993@cygnus.com> <375078A4.5A093F2C@vinschen.de> <19990529193554.A1338@cygnus.com> <3751397F.19EFD759@vinschen.de> <19990530124814.A718@cygnus.com> <37519478.6BF756F6@vinschen.de> <19990530210719.A946@cygnus.com> <375261EA.DD9290F1@vinschen.de> <19990531115344.A1606@cygnus.com> <3752CD33.C49540D9@vinschen.de> <19990531200731.A3966@cygnus.com> Message-ID: <3753D1F3.4710C353@vinschen.de> Hi Chris, Chris Faylor wrote: > > On Mon, May 31, 1999 at 07:56:03PM +0200, Corinna Vinschen wrote: > >Chris Faylor wrote: > >> Also, I was thinking that CYGWIN=ntsec should be *on* by default. That > >> way it will be tested by more people. Can you add a check in environ.cc > >> to turn this on if it's running under NT (assuming you agree)? > > > >Done. It's essential now, to document this in the installation instructions: NT users have to create /etc/passwd and /etc/group or they have to set CYGWIN=nontsec if they don't want to use NT security. Michael Hirmke has corrected my ntsec documentation (oh god, my English is SO bad!) and it's definitely more readable now. NT security is so complex, that I think, the document should be part of winsup. Do you agree? I have attached patches to mkpasswd.c and mkgroup.c for better working with ntsec. mkpasswd and mkgroup both list the correct native name of the `Everyone' group (SID 0) and mkgroup additionally lists the native name of the `None' group (SID 513) now. On a workstation the commands `mkpasswd -l -g' and `mkgroup -l' result in real complete passwd and group files now. I don't know, how it looks like in domains. Unfortunately there is no solution for correct primary group assignment outside of domains as I mention in the ntsec doc. Regards, Corinna ChangeLog: ========== Thu Jun 1 14:17:00 1999 Corinna Vinschen * utils/mkpasswd.c: Changed to output native names of well known group `Everyone' (SID 0). * utils/mkgroup.c: Ditto plus output of native name of well known group `None' (SID 513). Index: mkpasswd.c =================================================================== RCS file: /src/cvsroot/winsup-990526/utils/mkpasswd.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 mkpasswd.c --- mkpasswd.c 1999/05/28 19:28:24 1.1.1.1 +++ mkpasswd.c 1999/06/01 12:20:26 @@ -22,6 +22,9 @@ #include +SID_IDENTIFIER_AUTHORITY sid_world_auth = {SECURITY_WORLD_SID_AUTHORITY}; +SID_IDENTIFIER_AUTHORITY sid_nt_auth = {SECURITY_NT_AUTHORITY}; + #ifndef min #define min(a,b) (((a)<(b))?(a):(b)) #endif @@ -167,9 +170,9 @@ enum_local_groups () return 0; } - gid = *GetSidSubAuthority (psid, 1); + gid = *GetSidSubAuthority (psid, *GetSidSubAuthorityCount(psid) - 1); - printf ("%s::%ld:0:::\n", localgroup_name, gid); + printf ("%s:*:%ld:%ld:::\n", localgroup_name, gid, gid); } NetApiBufferFree (buffer); @@ -208,6 +211,11 @@ main (int argc, char **argv) int domain_name_specified = 0; int i; + char name[256], dom[256]; + DWORD len, len2; + PSID sid; + SID_NAME_USE use; + if (argc == 1) usage (); @@ -243,6 +251,23 @@ main (int argc, char **argv) exit (1); } + /* + * Get `Everyone' group + */ + if (AllocateAndInitializeSid (&sid_world_auth, 1, SECURITY_WORLD_RID, + 0, 0, 0, 0, 0, 0, 0, &sid)) + { + if (LookupAccountSid (NULL, sid, + name, (len = 256, &len), + dom, (len2 = 256, &len), + &use)) + printf ("%s:*:%d:%d:::\n", name, SECURITY_WORLD_RID, SECURITY_WORLD_RID); + FreeSid (sid); + } + + if (print_local_groups) + enum_local_groups (); + if (print_domain) { if (domain_name_specified) @@ -262,9 +287,6 @@ main (int argc, char **argv) if (print_local) enum_users (NULL); - - if (print_local_groups) - enum_local_groups (); return 0; } Index: mkgroup.c =================================================================== RCS file: /src/cvsroot/winsup-990526/utils/mkgroup.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 mkgroup.c --- mkgroup.c 1999/05/28 19:28:24 1.1.1.1 +++ mkgroup.c 1999/06/01 12:19:28 @@ -16,6 +16,8 @@ #include #include +SID_IDENTIFIER_AUTHORITY sid_world_auth = {SECURITY_WORLD_SID_AUTHORITY}; + #ifndef min #define min(a,b) (((a)<(b))?(a):(b)) #endif @@ -53,6 +55,70 @@ uni2ansi (LPWSTR wcs, char *mbs) *mbs = '\0'; } +int +enum_local_groups () +{ + LOCALGROUP_INFO_0 *buffer; + DWORD entriesread = 0; + DWORD totalentries = 0; + DWORD resume_handle = 0; + + do + { + DWORD i; + DWORD rc = NetLocalGroupEnum (NULL, 0, (LPBYTE *) & buffer, 1024, + &entriesread, &totalentries, &resume_handle); + + switch (rc) + { + case ERROR_ACCESS_DENIED: + fprintf (stderr, "Access denied\n"); + exit (1); + + case ERROR_MORE_DATA: + case ERROR_SUCCESS: + break; + + default: + fprintf (stderr, "NetUserEnum() failed with %ld\n", rc); + exit (1); + } + + for (i = 0; i < entriesread; i++) + { + char localgroup_name[100]; + char domain_name[100]; + DWORD domname_len = 100; + char psid_buffer[1024]; + PSID psid = (PSID) psid_buffer; + DWORD sid_length = 1024; + DWORD gid; + SID_NAME_USE acc_type; + uni2ansi (buffer[i].lgrpi0_name, localgroup_name); + + if (!LookupAccountName (NULL, localgroup_name, psid, + &sid_length, domain_name, &domname_len, + &acc_type)) + { + int code = GetLastError (); + fprintf (stderr, "LookupAccountName(%s) failed with %d\n", + localgroup_name, code); + return 0; + } + + gid = *GetSidSubAuthority (psid, *GetSidSubAuthorityCount(psid) - 1); + + printf ("%s::%ld:\n", localgroup_name, gid); + } + + NetApiBufferFree (buffer); + + } + while (entriesread < totalentries); + + return 0; +} + void enum_groups (LPWSTR servername) { @@ -126,6 +192,11 @@ main (int argc, char **argv) int domain_specified = 0; int i; + char name[256], dom[256]; + DWORD len, len2; + PSID sid, csid; + SID_NAME_USE use; + if (argc == 1) usage (); @@ -150,6 +221,51 @@ main (int argc, char **argv) } } } + + /* + * Get `Everyone' group + */ + if (AllocateAndInitializeSid (&sid_world_auth, 1, SECURITY_WORLD_RID, + 0, 0, 0, 0, 0, 0, 0, &sid)) + { + if (LookupAccountSid (NULL, sid, + name, (len = 256, &len), + dom, (len2 = 256, &len), + &use)) + printf ("%s::%d:\n", name, SECURITY_WORLD_RID); + FreeSid (sid); + } + + /* + * Get `None' group + */ + GetComputerName (name, (len = 256, &len)); + csid = (PSID) malloc (1024); + LookupAccountName (NULL, name, + csid, (len = 1024, &len), + dom, (len2 = 256, &len), + &use); + if (AllocateAndInitializeSid (GetSidIdentifierAuthority (csid), + *GetSidSubAuthorityCount (csid), + *GetSidSubAuthority (csid, 0), + *GetSidSubAuthority (csid, 1), + *GetSidSubAuthority (csid, 2), + *GetSidSubAuthority (csid, 3), + 513, + 0, + 0, + 0, + &sid)) + { + if (LookupAccountSid (NULL, sid, + name, (len = 256, &len), + dom, (len2 = 256, &len), + &use)) + printf ("%s::513:\n", name); + FreeSid (sid); + } + free (csid); + if (print_domain) { if (domain_specified) @@ -168,9 +284,7 @@ main (int argc, char **argv) } if (print_local) - enum_groups (NULL); - - printf ("Everyone::0:\n"); + enum_local_groups (); return 0; } From corinna@vinschen.de Tue Jun 1 06:24:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Tue, 01 Jun 1999 06:24:00 -0000 Subject: mkpasswd and mkgroup patch Message-ID: <3753DE93.94F7E870@vinschen.de> Sorry, I've forgotten the `system' entry for /etc/passwd and /etc/group. The attached patch replaces the previous patch completely. The ChangeLog, too. Regards, Corinna Thu Jun 1 14:17:00 1999 Corinna Vinschen * utils/mkpasswd.c: Changed to output native names of well known groups `Everyone' (SID 0) and `system' (SID 18). * utils/mkgroup.c: Ditto plus output of native name of well known group `None' (SID 513). -- new mail address: mailto:corinna@vinschen.de Index: mkpasswd.c =================================================================== RCS file: /src/cvsroot/winsup-990526/utils/mkpasswd.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 mkpasswd.c --- mkpasswd.c 1999/05/28 19:28:24 1.1.1.1 +++ mkpasswd.c 1999/06/01 13:16:23 @@ -22,6 +22,9 @@ #include +SID_IDENTIFIER_AUTHORITY sid_world_auth = {SECURITY_WORLD_SID_AUTHORITY}; +SID_IDENTIFIER_AUTHORITY sid_nt_auth = {SECURITY_NT_AUTHORITY}; + #ifndef min #define min(a,b) (((a)<(b))?(a):(b)) #endif @@ -167,9 +170,9 @@ enum_local_groups () return 0; } - gid = *GetSidSubAuthority (psid, 1); + gid = *GetSidSubAuthority (psid, *GetSidSubAuthorityCount(psid) - 1); - printf ("%s::%ld:0:::\n", localgroup_name, gid); + printf ("%s:*:%ld:%ld:::\n", localgroup_name, gid, gid); } NetApiBufferFree (buffer); @@ -208,6 +211,11 @@ main (int argc, char **argv) int domain_name_specified = 0; int i; + char name[256], dom[256]; + DWORD len, len2; + PSID sid; + SID_NAME_USE use; + if (argc == 1) usage (); @@ -243,6 +251,39 @@ main (int argc, char **argv) exit (1); } + /* + * Get `Everyone' group + */ + if (AllocateAndInitializeSid (&sid_world_auth, 1, SECURITY_WORLD_RID, + 0, 0, 0, 0, 0, 0, 0, &sid)) + { + if (LookupAccountSid (NULL, sid, + name, (len = 256, &len), + dom, (len2 = 256, &len), + &use)) + printf ("%s:*:%d:%d:::\n", name, SECURITY_WORLD_RID, SECURITY_WORLD_RID); + FreeSid (sid); + } + + /* + * Get `system' group + */ + if (AllocateAndInitializeSid (&sid_nt_auth, 1, SECURITY_LOCAL_SYSTEM_RID, + 0, 0, 0, 0, 0, 0, 0, &sid)) + { + if (LookupAccountSid (NULL, sid, + name, (len = 256, &len), + dom, (len2 = 256, &len), + &use)) + printf ("%s:*:%d:%d:::\n", name, + SECURITY_LOCAL_SYSTEM_RID, + SECURITY_LOCAL_SYSTEM_RID); + FreeSid (sid); + } + + if (print_local_groups) + enum_local_groups (); + if (print_domain) { if (domain_name_specified) @@ -262,9 +303,6 @@ main (int argc, char **argv) if (print_local) enum_users (NULL); - - if (print_local_groups) - enum_local_groups (); return 0; } Index: mkgroup.c =================================================================== RCS file: /src/cvsroot/winsup-990526/utils/mkgroup.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 mkgroup.c --- mkgroup.c 1999/05/28 19:28:24 1.1.1.1 +++ mkgroup.c 1999/06/01 13:15:16 @@ -16,6 +16,9 @@ #include #include +SID_IDENTIFIER_AUTHORITY sid_world_auth = {SECURITY_WORLD_SID_AUTHORITY}; +SID_IDENTIFIER_AUTHORITY sid_nt_auth = {SECURITY_NT_AUTHORITY}; + #ifndef min #define min(a,b) (((a)<(b))?(a):(b)) #endif @@ -53,6 +56,70 @@ uni2ansi (LPWSTR wcs, char *mbs) *mbs = '\0'; } +int +enum_local_groups () +{ + LOCALGROUP_INFO_0 *buffer; + DWORD entriesread = 0; + DWORD totalentries = 0; + DWORD resume_handle = 0; + + do + { + DWORD i; + DWORD rc = NetLocalGroupEnum (NULL, 0, (LPBYTE *) & buffer, 1024, + &entriesread, &totalentries, &resume_handle); + + switch (rc) + { + case ERROR_ACCESS_DENIED: + fprintf (stderr, "Access denied\n"); + exit (1); + + case ERROR_MORE_DATA: + case ERROR_SUCCESS: + break; + + default: + fprintf (stderr, "NetUserEnum() failed with %ld\n", rc); + exit (1); + } + + for (i = 0; i < entriesread; i++) + { + char localgroup_name[100]; + char domain_name[100]; + DWORD domname_len = 100; + char psid_buffer[1024]; + PSID psid = (PSID) psid_buffer; + DWORD sid_length = 1024; + DWORD gid; + SID_NAME_USE acc_type; + uni2ansi (buffer[i].lgrpi0_name, localgroup_name); + + if (!LookupAccountName (NULL, localgroup_name, psid, + &sid_length, domain_name, &domname_len, + &acc_type)) + { + int code = GetLastError (); + fprintf (stderr, "LookupAccountName(%s) failed with %d\n", + localgroup_name, code); + return 0; + } + + gid = *GetSidSubAuthority (psid, *GetSidSubAuthorityCount(psid) - 1); + + printf ("%s::%ld:\n", localgroup_name, gid); + } + + NetApiBufferFree (buffer); + + } + while (entriesread < totalentries); + + return 0; +} + void enum_groups (LPWSTR servername) { @@ -126,6 +193,11 @@ main (int argc, char **argv) int domain_specified = 0; int i; + char name[256], dom[256]; + DWORD len, len2; + PSID sid, csid; + SID_NAME_USE use; + if (argc == 1) usage (); @@ -150,6 +222,65 @@ main (int argc, char **argv) } } } + + /* + * Get `Everyone' group + */ + if (AllocateAndInitializeSid (&sid_world_auth, 1, SECURITY_WORLD_RID, + 0, 0, 0, 0, 0, 0, 0, &sid)) + { + if (LookupAccountSid (NULL, sid, + name, (len = 256, &len), + dom, (len2 = 256, &len), + &use)) + printf ("%s::%d:\n", name, SECURITY_WORLD_RID); + FreeSid (sid); + } + + /* + * Get `system' group + */ + if (AllocateAndInitializeSid (&sid_nt_auth, 1, SECURITY_LOCAL_SYSTEM_RID, + 0, 0, 0, 0, 0, 0, 0, &sid)) + { + if (LookupAccountSid (NULL, sid, + name, (len = 256, &len), + dom, (len2 = 256, &len), + &use)) + printf ("%s::%d:\n", name, SECURITY_LOCAL_SYSTEM_RID); + FreeSid (sid); + } + + /* + * Get `None' group + */ + GetComputerName (name, (len = 256, &len)); + csid = (PSID) malloc (1024); + LookupAccountName (NULL, name, + csid, (len = 1024, &len), + dom, (len2 = 256, &len), + &use); + if (AllocateAndInitializeSid (GetSidIdentifierAuthority (csid), + *GetSidSubAuthorityCount (csid), + *GetSidSubAuthority (csid, 0), + *GetSidSubAuthority (csid, 1), + *GetSidSubAuthority (csid, 2), + *GetSidSubAuthority (csid, 3), + 513, + 0, + 0, + 0, + &sid)) + { + if (LookupAccountSid (NULL, sid, + name, (len = 256, &len), + dom, (len2 = 256, &len), + &use)) + printf ("%s::513:\n", name); + FreeSid (sid); + } + free (csid); + if (print_domain) { if (domain_specified) @@ -168,9 +299,7 @@ main (int argc, char **argv) } if (print_local) - enum_groups (NULL); - - printf ("Everyone::0:\n"); + enum_local_groups (); return 0; } From corinna@vinschen.de Tue Jun 1 06:40:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Tue, 01 Jun 1999 06:40:00 -0000 Subject: [Fwd: shm] Message-ID: <3753E298.16B46F37@vinschen.de> I forward this, because I noticed this problem only when I read Suhaib's mail. IMHO, the `mmap' problem should be solved, too, before releasing B21. As minimal change, the call to `CreateFileMapping' should get a `sec_all' security descriptor instead of `sec_none'. Corinna Vinschen wrote: > > Horak Daniel wrote: > > > > > Has anyone a SVR4 style shared memmory for Cygwin > > > (shmget/shmctl/shmat)? I need it for X-server > > > for Cygwin Development. > > > > > > The ipc available for Cygwin from France (do not remember the URL) has > > > problems. Its headers gives the problems. > > > > I am using the cygipc library v1.03 > > ( http://www.multione.capgemini.fr/tools/pack_ipc/ ) succesfully in the port > > of PostgreSQL database system. It required only to comment CURRENT_TIME in > > some header. > > > > Dan > > Caution! > > The security settings of this package are not sufficent for multi user > systems! The security descriptor, that is given to `CreateSemaphore' > is a default descriptor. The result is, that only the creator/owner > of the semaphore may use it. > > Moreover, the cygwin call `mmap' which is used in the package, is not > implemented with sufficent correspondence between the given permissions > and the resulting security descriptor in the windows call > `CreateFileMapping'. It uses the default descriptor, too :( > > Regards, > Corinna -- new mail address: mailto:corinna@vinschen.de From corinna@vinschen.de Tue Jun 1 15:52:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Tue, 01 Jun 1999 15:52:00 -0000 Subject: patch to net.cc (get_if_flags) [Fwd: ioctl() SOS -- Please help] Message-ID: <37546414.C95B36A5@vinschen.de> Corinna Vinschen wrote: > > Corinna Vinschen wrote: > > > > "Ashish C. Nagre" wrote: > > > I have made a strange observation, when the following call is made: > > > [...] > > In case of address 0.0.0.0, the cygwin DLL knows, that the interface > > isn't connected and so returns the flags > > IFF_NOTRAILERS | IFF_BROADCAST > > The hex value of the above flags is 0x34. > > Oops, this isn't correct, is it? I have checked it on linux. The > ppp interfaces, which are not connected are nevertheless up and > running! > > I will patch it ASAP. This dumb change was originaly contributed by me in December :-( Sigh! Here's the correction. Corinna ChangeLog: ========== Fri May 28 21:10:33 1999 Corinna Vinschen * net.cc (get_if_flags): Change the UP and RUNNING state of disconnected RAS interfaces to true. Index: net.cc =================================================================== RCS file: /src/cvsroot/winsup-990526/net.cc,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 net.cc --- net.cc 1999/05/28 19:27:54 1.1.1.1 +++ net.cc 1999/06/01 22:24:56 @@ -1455,15 +1455,13 @@ get_ifconf (struct ifconf *ifc, int what static int get_if_flags (struct ifreq *ifr) { - short flags = IFF_NOTRAILERS; struct sockaddr_in *sa = (struct sockaddr_in *) &ifr->ifr_addr; - if (sa->sin_addr.s_addr == INADDR_ANY) - flags |= IFF_BROADCAST; - else if (sa->sin_addr.s_addr == INADDR_LOOPBACK) - flags |= IFF_LOOPBACK | IFF_UP | IFF_RUNNING; + short flags = IFF_NOTRAILERS | IFF_UP | IFF_RUNNING; + if (sa->sin_addr.s_addr == INADDR_LOOPBACK) + flags |= IFF_LOOPBACK; else - flags |= IFF_BROADCAST | IFF_UP | IFF_RUNNING; + flags |= IFF_BROADCAST; ifr->ifr_flags = flags; return 0; From noer@cygnus.com Wed Jun 2 17:17:00 1999 From: noer@cygnus.com (Geoffrey Noer) Date: Wed, 02 Jun 1999 17:17:00 -0000 Subject: Native rebuilding with latest snapshot Message-ID: <19990602171747.A27240@cygnus.com> With the latest patches from Corinna, I'm seeing basically good behavior with the latest snapshots but now I am running into problems with running configure on my NT system. Although I have admin privs, I get some permission denied errors I never had before. One error message: 0 0 [main] E:\bin\sh.exe 1965 fhandler_base::fork_fixup: move-if-change - error 6, handle 0x20 I also see in the configure output: chmod: ./config.new: Permission denied So it looks like there is still some stuff to look into... -- Geoffrey Noer Email: noer@cygnus.com Cygnus Solutions From cgf@cygnus.com Wed Jun 2 19:01:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Wed, 02 Jun 1999 19:01:00 -0000 Subject: Native rebuilding with latest snapshot References: <19990602171747.A27240@cygnus.com> <19990602171747.A27240@cygnus.com> Message-ID: <19990602220234.A2320@cygnus.com> On Wed, Jun 02, 1999 at 05:17:47PM -0700, Geoffrey Noer wrote: >With the latest patches from Corinna, I'm seeing basically good >behavior with the latest snapshots but now I am running into problems >with running configure on my NT system. Although I have admin privs, >I get some permission denied errors I never had before. > >One error message: > > 0 0 [main] E:\bin\sh.exe 1965 fhandler_base::fork_fixup: >move-if-change - error 6, handle 0x20 > >I also see in the configure output: > > chmod: ./config.new: Permission denied > >So it looks like there is still some stuff to look into... Do you see the same behavior with CYGWIN=nontsec? cgf From corinna@vinschen.de Thu Jun 3 04:54:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Thu, 03 Jun 1999 04:54:00 -0000 Subject: Native rebuilding with latest snapshot References: <19990602171747.A27240@cygnus.com> Message-ID: <37566A7C.24BA6E8B@vinschen.de> Geoffrey Noer wrote: > > With the latest patches from Corinna, I'm seeing basically good > behavior with the latest snapshots but now I am running into problems > with running configure on my NT system. Although I have admin privs, > I get some permission denied errors I never had before. > > One error message: > > 0 0 [main] E:\bin\sh.exe 1965 fhandler_base::fork_fixup: > move-if-change - error 6, handle 0x20 > > I also see in the configure output: > > chmod: ./config.new: Permission denied > > So it looks like there is still some stuff to look into... This is naturaly possible, if your /etc/passwd and /etc/group files aren't correctly filled. The correspondence between UID, GID and name is essential. You should check the `security' entry in the files properties box in NT explorer. It would be nice, to send me an STRACE=0x50 output of a situation, where these `permission denied' messages are produced. You should then send your /etc/passwd and /etc/group files, too. TIA, Corinna From cgf@cygnus.com Thu Jun 3 08:54:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Thu, 03 Jun 1999 08:54:00 -0000 Subject: Text version of Windows error messages in small_printf considered harmful Message-ID: <19990603115454.A1505@cygnus.com> Now that I've had the chance to use the extended error messages that Mumit recently added to smallprint.c, I have to say that I'm not thrilled. The error messages extend the length of the line so that things wrap in a way that makes it hard to read. Worse, I've received a couple of strace logs from non-US users and the error messages are incomprehensible to me. Another problem is that it is not easy to figure out exactly which error *code* is being displayed even when the error is in English. Because of this, I have conditionalized this code in recent snapshots. It's off by default. I'm thinking that an alternative is to add the possibility to create text messages as an STRACE option. I have always wanted to write an strace program rather than using the kludgey environment variable method. If we did this, we could do something like 'strace --text file.exe' to produce error message logs with text error messages. -- cgf@cygnus.com http://www.cygnus.com/ From corinna@vinschen.de Fri Jun 4 01:46:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Fri, 04 Jun 1999 01:46:00 -0000 Subject: Text version of Windows error messages in small_printf considered harmful References: <19990603115454.A1505@cygnus.com> Message-ID: <37579252.34EB714E@vinschen.de> Chris Faylor wrote: > > Now that I've had the chance to use the extended error messages that > Mumit recently added to smallprint.c, I have to say that I'm not thrilled. > The error messages extend the length of the line so that things wrap > in a way that makes it hard to read. Worse, I've received a couple of > strace logs from non-US users and the error messages are incomprehensible > to me. Another problem is that it is not easy to figure out exactly > which error *code* is being displayed even when the error is in English. I agree. I'm native german and it's easier for me to work with error codes than with german or english error messages. It's definitely easier to find related information with the error code instead of with the error message. > Because of this, I have conditionalized this code in recent snapshots. > It's off by default. > I'm thinking that an alternative is to add the > possibility to create text messages as an STRACE option. I have always > wanted to write an strace program rather than using the kludgey environment > variable method. If we did this, we could do something like > 'strace --text file.exe' to produce error message logs with text error > messages. IMHO, the environment variable method is ok. It allows, to debug an application, that is started from the service manager. The `strace' program would nevertheless be a convenient method. I like this idea, too, and I think, this program can be very easy: It only has to control the setting of the environment variable. Regards, Corinna From cgf@cygnus.com Fri Jun 4 05:36:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Fri, 04 Jun 1999 05:36:00 -0000 Subject: Text version of Windows error messages in small_printf considered harmful References: <19990603115454.A1505@cygnus.com> <37579252.34EB714E@vinschen.de> <37579252.34EB714E@vinschen.de> Message-ID: <19990604083649.C772@cygnus.com> On Fri, Jun 04, 1999 at 10:46:10AM +0200, Corinna Vinschen wrote: >Chris Faylor wrote: >> Because of this, I have conditionalized this code in recent snapshots. >> It's off by default. >> I'm thinking that an alternative is to add the >> possibility to create text messages as an STRACE option. I have always >> wanted to write an strace program rather than using the kludgey environment >> variable method. If we did this, we could do something like >> 'strace --text file.exe' to produce error message logs with text error >> messages. > >IMHO, the environment variable method is ok. It allows, to debug an >application, that is started from the service manager. >The `strace' program would nevertheless be a convenient method. I >like this idea, too, and I think, this program can be very easy: >It only has to control the setting of the environment variable. I was actually thinking of using OutputDebugString for strace_printf, doing a simple 'if (strace ()) strace_printf (...)', letting the strace program filter out the stuff that it needed. The obviously crucial point here, though, is that the strace program should not be a cygwin program. Otherwise it's usefulness will be quite limited. -chris From earnie_boyd@yahoo.com Mon Jun 7 06:50:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Mon, 07 Jun 1999 06:50:00 -0000 Subject: Missing from ddeml.h Message-ID: <19990607135623.2972.rocketmail@web116.yahoomail.com> typedef struct tagHSZPAIR { HSZ hszSvc; HSZ hszTopic; } HSZPAIR; While building tcl8.1 I've discovered the above to be missing from ddeml.h. I'm using Anders headers. === YAWIA, Earnie Boyd < mailto:earnie_boyd@yahoo.com > Newbies, please visit < http://www.freeyellow.com/members5/gw32/index.html > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From khan@xraylith.wisc.EDU Mon Jun 7 09:59:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Mon, 07 Jun 1999 09:59:00 -0000 Subject: Text version of Windows error messages in small_printf considered harmful References: <37579252.34EB714E@vinschen.de> Message-ID: <199906071552.KAA02703@mercury.xraylith.wisc.edu> Corinna Vinschen writes: > Chris Faylor wrote: > > > > Now that I've had the chance to use the extended error messages that > > Mumit recently added to smallprint.c, I have to say that I'm not thrilled. > > The error messages extend the length of the line so that things wrap > > in a way that makes it hard to read. Worse, I've received a couple of > > strace logs from non-US users and the error messages are incomprehensible > > to me. Another problem is that it is not easy to figure out exactly > > which error *code* is being displayed even when the error is in English. > > I agree. I'm native german and it's easier for me to work with error > codes than with german or english error messages. It's definitely > easier to find related information with the error code instead of with > the error message. I on the other hand find it *very* cumbersome to look up error messages when given just numbers; eg., 'dlopen: win32 error 113' or something similar means nothing to a user, when something like 'dlopen: can't find shared library' means a lot more. However, since the code is problematic, it should be taken out or turned on via a env variable as Chris suggests. The language issue is trivial -- just force the language to be US English instead of native in the FormatMessage. IMO One way to do this correctly is the following: - tag a set of these error codes as something we would like to display using a human-readable message. - have a associative translation table using the error code as the key; the table will have error messages formatted like sys_errlist to provide Unix-like consistency (eg., short and no embedded newlines!). - display only these messages as text. Over time, we can keep on expanding the error translation table. > > > Because of this, I have conditionalized this code in recent snapshots. > > It's off by default. > > I'm thinking that an alternative is to add the > > possibility to create text messages as an STRACE option. I have always > > wanted to write an strace program rather than using the kludgey environment > > variable method. If we did this, we could do something like > > 'strace --text file.exe' to produce error message logs with text error > > messages. > > IMHO, the environment variable method is ok. It allows, to debug an > application, that is started from the service manager. > The `strace' program would nevertheless be a convenient method. I > like this idea, too, and I think, this program can be very easy: > It only has to control the setting of the environment variable. > I do like the strace option, but please keep users in mind. Regards, Mumit From khan@xraylith.wisc.EDU Mon Jun 7 10:01:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Mon, 07 Jun 1999 10:01:00 -0000 Subject: Missing from ddeml.h References: <19990607135623.2972.rocketmail@web116.yahoomail.com> Message-ID: <199906071554.KAA02713@mercury.xraylith.wisc.edu> Earnie Boyd writes: > typedef struct tagHSZPAIR { > HSZ hszSvc; > HSZ hszTopic; > } HSZPAIR; > > While building tcl8.1 I've discovered the above to be missing from ddeml.h. > I'm using Anders headers. You should use my patches (URL below) until Anders makes a new release. There are a few other patches to the headers as well. See: http://www.xraylith.wisc.edu/~khan/software/tcl/ Regards, Mumit From mthomas@cabletron.com Mon Jun 7 10:09:00 1999 From: mthomas@cabletron.com (Thomas, Mike) Date: Mon, 07 Jun 1999 10:09:00 -0000 Subject: Environment Variables Message-ID: <0F9F4B0DB88BD21182C20008C70922EADEF9C4@corp-exc5.ctron.com> I have a quick question... In b18 environment variables were being changed to uppercase before a executing a new process. In b20 is this still the case? If so is there a mechinisim by which we can change this to not alter the environment Maybe a registry entry? Thanks, Mike From cgf@cygnus.com Mon Jun 7 10:14:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Mon, 07 Jun 1999 10:14:00 -0000 Subject: Text version of Windows error messages in small_printf considered harmful References: <37579252.34EB714E@vinschen.de> <199906071552.KAA02703@mercury.xraylith.wisc.edu> <199906071552.KAA02703@mercury.xraylith.wisc.edu> Message-ID: <19990607131522.A1738@cygnus.com> On Mon, Jun 07, 1999 at 10:52:55AM -0500, Mumit Khan wrote: >Corinna Vinschen writes: >> Chris Faylor wrote: >> > Now that I've had the chance to use the extended error messages that >> > Mumit recently added to smallprint.c, I have to say that I'm not thrilled. >> > The error messages extend the length of the line so that things wrap >> > in a way that makes it hard to read. Worse, I've received a couple of >> > strace logs from non-US users and the error messages are incomprehensible >> > to me. Another problem is that it is not easy to figure out exactly >> > which error *code* is being displayed even when the error is in English. >> >> I agree. I'm native german and it's easier for me to work with error >> codes than with german or english error messages. It's definitely >> easier to find related information with the error code instead of with >> the error message. > >I on the other hand find it *very* cumbersome to look up error messages >when given just numbers; eg., 'dlopen: win32 error 113' or something >similar means nothing to a user, when something like 'dlopen: can't find >shared library' means a lot more. Sure it does. But when it is a slightly more obscure error message the correspondence to an ERROR_* define might be more useful. In the Win32 API documentation they do mention ERROR_* defines from time to time, although not as often as they should. The definitions in include/winerror.h do not contain the text of the message so, when you're displaying messages, you have to guess what message corresponds to what ERROR_* define. Of course, we could clutter up the strace output even more by including the error number along with the error text but one of the problems is that the strace files are a lot larger and a lot harder to read with the addition of error messages. Adding more text doesn't seem like the way to go to me. >However, since the code is problematic, it should be taken out or turned >on via a env variable as Chris suggests. > >The language issue is trivial -- just force the language to be US English >instead of native in the FormatMessage. How does this work with "keeping the users in mind", then? This helps only US users. >IMO One way to do this correctly is the following: > >- tag a set of these error codes as something we would like to display > using a human-readable message. >- have a associative translation table using the error code as the key; > the table will have error messages formatted like sys_errlist to > provide Unix-like consistency (eg., short and no embedded newlines!). >- display only these messages as text. I don't see any reason for this logic to be inside cygwin, actually. The translation could easily be provided by some sort of strace file filter or, eventually, by an strace program itself. cgf From cgf@cygnus.com Mon Jun 7 10:17:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Mon, 07 Jun 1999 10:17:00 -0000 Subject: Environment Variables References: <0F9F4B0DB88BD21182C20008C70922EADEF9C4@corp-exc5.ctron.com> <0F9F4B0DB88BD21182C20008C70922EADEF9C4@corp-exc5.ctron.com> Message-ID: <19990607131838.B1738@cygnus.com> On Mon, Jun 07, 1999 at 01:08:42PM -0400, Thomas, Mike wrote: >I have a quick question... In b18 environment variables were being changed >to uppercase before a executing a new process. In b20 is this still the >case? If so is there a mechinisim by which we can change this to not alter >the environment Maybe a registry entry? I don't know the answer off the top of my head. The actual code involved is is in environ.cc. I'd suggest that you look there and write some simple test cases to supply you're own answer. cgf From earnie_boyd@yahoo.com Mon Jun 7 11:01:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Mon, 07 Jun 1999 11:01:00 -0000 Subject: Missing from ddeml.h Message-ID: <19990607180327.17165.rocketmail@web110.yahoomail.com> --- Mumit Khan wrote: > Earnie Boyd writes: > > typedef struct tagHSZPAIR { > > HSZ hszSvc; > > HSZ hszTopic; > > } HSZPAIR; > > > > While building tcl8.1 I've discovered the above to be missing from ddeml.h. > > > I'm using Anders headers. > > You should use my patches (URL below) until Anders makes a new release. > There are a few other patches to the headers as well. See: > > http://www.xraylith.wisc.edu/~khan/software/tcl/ > I did use your patches. I downloaded 5/10/1999 are there new ones? === YAWIA, Earnie Boyd < mailto:earnie_boyd@yahoo.com > Newbies, please visit < http://www.freeyellow.com/members5/gw32/index.html > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From mthomas@cabletron.com Mon Jun 7 12:48:00 1999 From: mthomas@cabletron.com (Thomas, Mike) Date: Mon, 07 Jun 1999 12:48:00 -0000 Subject: Environment Variables Message-ID: <0F9F4B0DB88BD21182C20008C70922EADEF9C7@corp-exc5.ctron.com> I didn't have the source on my system, I'm extracting it now, but I was in hopes someone (maybe dj) would have known. If there isn't a way to do what I ask I like to see the addition of a way to specify whether to change the environment or not. Mike -----Original Message----- From: Chris Faylor [ mailto:cgf@cygnus.com ] Sent: Monday, June 07, 1999 1:19 PM To: Thomas, Mike Cc: cygwin-developers@sourceware.cygnus.com Subject: Re: Environment Variables On Mon, Jun 07, 1999 at 01:08:42PM -0400, Thomas, Mike wrote: >I have a quick question... In b18 environment variables were being changed >to uppercase before a executing a new process. In b20 is this still the >case? If so is there a mechinisim by which we can change this to not alter >the environment Maybe a registry entry? I don't know the answer off the top of my head. The actual code involved is is in environ.cc. I'd suggest that you look there and write some simple test cases to supply you're own answer. cgf From mthomas@cabletron.com Mon Jun 7 13:02:00 1999 From: mthomas@cabletron.com (Thomas, Mike) Date: Mon, 07 Jun 1999 13:02:00 -0000 Subject: Environment Variables Message-ID: <0F9F4B0DB88BD21182C20008C70922EADEF9C8@corp-exc5.ctron.com> Ok it is still the same as in b18, this breaks us, we rely on environment variables to remain in the case they began in. Is this something we can suggest in some way to be added in a future rev? Mike PS I've been on this mailing list and quite since just after b18 :) Mainly because we are still using a heavily modified b18, mostly bug fixes that have been addressed in b20, except the environment.. -----Original Message----- From: Chris Faylor [ mailto:cgf@cygnus.com ] Sent: Monday, June 07, 1999 1:19 PM To: Thomas, Mike Cc: cygwin-developers@sourceware.cygnus.com Subject: Re: Environment Variables On Mon, Jun 07, 1999 at 01:08:42PM -0400, Thomas, Mike wrote: >I have a quick question... In b18 environment variables were being changed >to uppercase before a executing a new process. In b20 is this still the >case? If so is there a mechinisim by which we can change this to not alter >the environment Maybe a registry entry? I don't know the answer off the top of my head. The actual code involved is is in environ.cc. I'd suggest that you look there and write some simple test cases to supply you're own answer. cgf From cgf@cygnus.com Mon Jun 7 13:16:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Mon, 07 Jun 1999 13:16:00 -0000 Subject: Environment Variables References: <0F9F4B0DB88BD21182C20008C70922EADEF9C8@corp-exc5.ctron.com> <0F9F4B0DB88BD21182C20008C70922EADEF9C8@corp-exc5.ctron.com> Message-ID: <19990607161735.A763@cygnus.com> Ok. You finally forced me to check the code. Environment variables are uppercased in the first invocation of a cygwin process but subsequent children of that process do not do this. So, if you've used mixed case in environment variables prior to running BASH the mixed case will not show up in "env" output: c:\>set cArol=This is Carol c:\>bash bash-2.02$ env | grep cArol bash-2.02$ export Bobby="This is Bobby" bash-2.02$ env | grep "Bobby" Bobby=This is Bobby As far as suggesting something; this is open source. If you would like to submit a patch please feel free to do so. Otherwise, I have no plans on scheduling time to implement this behavior. cgf On Mon, Jun 07, 1999 at 04:01:30PM -0400, Thomas, Mike wrote: >Ok it is still the same as in b18, this breaks us, we rely on environment >variables to remain in the case they began in. > >Is this something we can suggest in some way to be added in a future rev? > >Mike > >PS I've been on this mailing list and quite since just after b18 :) > Mainly because we are still using a heavily modified b18, mostly bug > fixes that have been addressed in b20, except the environment.. > >-----Original Message----- >From: Chris Faylor [ mailto:cgf@cygnus.com ] >Sent: Monday, June 07, 1999 1:19 PM >To: Thomas, Mike >Cc: cygwin-developers@sourceware.cygnus.com >Subject: Re: Environment Variables > >On Mon, Jun 07, 1999 at 01:08:42PM -0400, Thomas, Mike wrote: >>I have a quick question... In b18 environment variables were being changed >>to uppercase before a executing a new process. In b20 is this still the >>case? If so is there a mechinisim by which we can change this to not alter >>the environment Maybe a registry entry? > >I don't know the answer off the top of my head. The actual code >involved is is in environ.cc. I'd suggest that you look there and write >some simple test cases to supply your own answer. From corinna@vinschen.de Mon Jun 7 13:29:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Mon, 07 Jun 1999 13:29:00 -0000 Subject: Text version of Windows error messages in small_printf considered harmful References: <37579252.34EB714E@vinschen.de> <199906071552.KAA02703@mercury.xraylith.wisc.edu> <19990607131522.A1738@cygnus.com> Message-ID: <375C2B73.9F01ED36@vinschen.de> Chris Faylor wrote: > > On Mon, Jun 07, 1999 at 10:52:55AM -0500, Mumit Khan wrote: > >Corinna Vinschen writes: > >> Chris Faylor wrote: > >> > Now that I've had the chance to use the extended error messages that > >> > Mumit recently added to smallprint.c, I have to say that I'm not thrilled. > >> > The error messages extend the length of the line so that things wrap > >> > in a way that makes it hard to read. Worse, I've received a couple of > >> > strace logs from non-US users and the error messages are incomprehensible > >> > to me. Another problem is that it is not easy to figure out exactly > >> > which error *code* is being displayed even when the error is in English. > >> > >> I agree. I'm native german and it's easier for me to work with error > >> codes than with german or english error messages. It's definitely > >> easier to find related information with the error code instead of with > >> the error message. > > > >I on the other hand find it *very* cumbersome to look up error messages > >when given just numbers; eg., 'dlopen: win32 error 113' or something > >similar means nothing to a user, when something like 'dlopen: can't find > >shared library' means a lot more. > [...] IMHO, the strace should help developers, not users. Shouldn't we simply use an _STRACE_ERRTXT flag or else as a first try? We would have both methods. Everyone may use it's prefered output type. Corinna From rdparker@butlermfg.org Mon Jun 7 17:00:00 1999 From: rdparker@butlermfg.org (Parker, Ron) Date: Mon, 07 Jun 1999 17:00:00 -0000 Subject: Text version of Windows error messages in small_printf considered harmful Message-ID: <23278.928800064.0@NO-ID-FOUND.mhonarc.com> I am hoping to kill this thread. I don't like the extended error messages for the same reasons others have given. Also forcing the output to English as recommended by Mumit won't work. On localized versions of Windows, English text is not guaranteed to be present. However, I also agree that I hate looking up error codes. So, I've attached the source for a small program that looks many of them up for you. -----Original Message----- From: Chris Faylor [ mailto:cgf@cygnus.com ] Sent: Thursday, June 03, 1999 10:55 AM To: cygwin-developers@sourceware.cygnus.com Subject: Text version of Windows error messages in small_printf considered harmful Now that I've had the chance to use the extended error messages that Mumit recently added to smallprint.c, I have to say that I'm not thrilled. The error messages extend the length of the line so that things wrap in a way that makes it hard to read. Worse, I've received a couple of strace logs from non-US users and the error messages are incomprehensible to me. Another problem is that it is not easy to figure out exactly which error *code* is being displayed even when the error is in English. Because of this, I have conditionalized this code in recent snapshots. It's off by default. I'm thinking that an alternative is to add the possibility to create text messages as an STRACE option. I have always wanted to write an strace program rather than using the kludgey environment variable method. If we did this, we could do something like 'strace --text file.exe' to produce error message logs with text error messages. -- cgf@cygnus.com http://www.cygnus.com/ From khan@xraylith.wisc.EDU Mon Jun 7 22:16:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Mon, 07 Jun 1999 22:16:00 -0000 Subject: Text version of Windows error messages in small_printf consid ered harmful References: <199906080001.TAA28669@thor.xraylith.wisc.edu> Message-ID: <199906080409.XAA24161@mercury.xraylith.wisc.edu> "Parker, Ron" writes: > > I am hoping to kill this thread. > > I don't like the extended error messages for the same reasons others have > given. > > Also forcing the output to English as recommended by Mumit won't work. On > localized versions of Windows, English text is not guaranteed to be present. I quite agree. Thanks for pointing out the localization issue. > > However, I also agree that I hate looking up error codes. So, I've attached > the source for a small program that looks many of them up for you. > Perhaps we should add this code (I haven't looked at it, but it's safe to assume it does essentially what my own little test code does) to the cygwin distrib in some form? Regards, Mumit From corinna@vinschen.de Tue Jun 8 02:13:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Tue, 08 Jun 1999 02:13:00 -0000 Subject: Text version of Windows error messages in small_printf considered harmful References: Message-ID: <375CDE7A.AF91F82E@vinschen.de> "Parker, Ron" wrote: > However, I also agree that I hate looking up error codes. So, I've attached > the source for a small program that looks many of them up for you. Wow! Thanks, Ron! That's the best solution, IMHO! Corinna From cgf@cygnus.com Tue Jun 8 08:16:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Tue, 08 Jun 1999 08:16:00 -0000 Subject: Text version of Windows error messages in small_printf considered harmful References: <375CDE7A.AF91F82E@vinschen.de> <375CDE7A.AF91F82E@vinschen.de> Message-ID: <19990608111714.B840@cygnus.com> On Tue, Jun 08, 1999 at 11:12:26AM +0200, Corinna Vinschen wrote: >"Parker, Ron" wrote: >> However, I also agree that I hate looking up error codes. So, I've attached >> the source for a small program that looks many of them up for you. > >Wow! >Thanks, Ron! > >That's the best solution, IMHO! Actually this is nice, but a *really* nice solution would be to actually scan the strace logs and insert the text where it finds windows errors. -chris From deo@logos-m.ru Tue Jun 8 10:01:00 1999 From: deo@logos-m.ru (Egor Duda) Date: Tue, 08 Jun 1999 10:01:00 -0000 Subject: default /etc/passwd contents Message-ID: <0873.990608@logos-m.ru> Hi! What do you think about changing cygwin behavior in case when /etc/passwd file isn't found? I think that it would be ok to create single entry in passwd_buf of some "default user", who cannot own any files and does not belong to any existing group. Something like "cygwin_default::::::none" Just like it's done for groups? I feel that it would be quite safe, if and will be assigned to some "reserved" values, i.e. not to be equal to any of real Windows UIDs and GIDs. I've made such patch and it saves me a lot of time while adopting cygwin port of ssh to be run on any machine even without cygwin installed. Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 Index: passwd.cc =================================================================== RCS file: /usr/local/src/cvs/cygnus/cygwin/winsup/passwd.cc,v retrieving revision 1.1.1.1 diff -u -2 -r1.1.1.1 passwd.cc --- passwd.cc 1999/04/10 14:55:02 1.1.1.1 +++ passwd.cc 1999/06/08 16:52:53 @@ -106,10 +106,9 @@ read_etc_passwd () { + char linebuf[1024]; FILE *f = fopen ("/etc/passwd", "r"); if (f) - { - char linebuf[1024]; - + { while (fgets (linebuf, sizeof (linebuf), f) != NULL) { @@ -119,5 +118,10 @@ fclose (f); - } + } + else + { + snprintf ( linebuf , sizeof ( linebuf ) , "cygwin_default::500:500::%s:none" , getenv ( "HOME" ) ) ; + add_pwd_line ( linebuf ) ; + } passwd_in_memory_p = 1; } From cgf@cygnus.com Tue Jun 8 10:12:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Tue, 08 Jun 1999 10:12:00 -0000 Subject: default /etc/passwd contents References: <0873.990608@logos-m.ru> <0873.990608@logos-m.ru> Message-ID: <19990608131346.A1137@cygnus.com> Hopefully Corinna will respond to this. I don't know how it impacts her security changes. If we are going to add a dummy line, why not actually make it meaningful and have it default to the current users's name, uid and gid? -chris On Tue, Jun 08, 1999 at 08:57:50PM +0400, Egor Duda wrote: > What do you think about changing cygwin behavior in case when >/etc/passwd file isn't found? I think that it would be ok to create >single entry in passwd_buf of some "default user", who cannot own any >files and does not belong to any existing group. Something like > > "cygwin_default::::::none" > >Just like it's done for groups? > >I feel that it would be quite safe, if and >will be assigned to some "reserved" values, i.e. not to be equal to >any of real Windows UIDs and GIDs. I've made such patch and it saves >me a lot of time while adopting cygwin port of ssh to be run on any >machine even without cygwin installed. > >Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 > >Index: passwd.cc >=================================================================== >RCS file: /usr/local/src/cvs/cygnus/cygwin/winsup/passwd.cc,v >retrieving revision 1.1.1.1 >diff -u -2 -r1.1.1.1 passwd.cc >--- passwd.cc 1999/04/10 14:55:02 1.1.1.1 >+++ passwd.cc 1999/06/08 16:52:53 >@@ -106,10 +106,9 @@ > read_etc_passwd () > { >+ char linebuf[1024]; > FILE *f = fopen ("/etc/passwd", "r"); > > if (f) >- { >- char linebuf[1024]; >- >+ { > while (fgets (linebuf, sizeof (linebuf), f) != NULL) > { >@@ -119,5 +118,10 @@ > > fclose (f); >- } >+ } >+ else >+ { >+ snprintf ( linebuf , sizeof ( linebuf ) , "cygwin_default::500:500::%s:none" , getenv ( "HOME" ) ) ; >+ add_pwd_line ( linebuf ) ; >+ } > passwd_in_memory_p = 1; > } > > -- cgf@cygnus.com http://www.cygnus.com/ From corinna@vinschen.de Tue Jun 8 13:32:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Tue, 08 Jun 1999 13:32:00 -0000 Subject: default /etc/passwd contents References: <0873.990608@logos-m.ru> <19990608131346.A1137@cygnus.com> Message-ID: <375D7CBF.27DAD5AA@vinschen.de> Chris Faylor wrote: > > Hopefully Corinna will respond to this. I don't know how it impacts > her security changes. It can't work with `ntsec' but it maybe useful with `nontsec'. > If we are going to add a dummy line, why not actually make it meaningful > and have it default to the current users's name, uid and gid? You can't get gid, because gid is only meaningful, if it's read from /etc/passwd. Remember: Outside of domains, no primary group exists. You only get name and uid but it should be possible, to use the administrators group (gid 544) as primary group in any case. Regards, Corinna -- new mail address: mailto:corinna@vinschen.de From corinna@vinschen.de Tue Jun 8 13:43:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Tue, 08 Jun 1999 13:43:00 -0000 Subject: default /etc/passwd contents References: <0873.990608@logos-m.ru> <19990608131346.A1137@cygnus.com> <375D7CBF.27DAD5AA@vinschen.de> Message-ID: <375D805A.90C9D21B@vinschen.de> Corinna Vinschen wrote: > [...] > You can't get gid, because gid is only meaningful, if it's read from > /etc/passwd. Remember: Outside of domains, no primary group exists. > You only get name and uid but it should be possible, to use the > administrators group (gid 544) as primary group in any case. Umm, I thought about it once more. This may also work with ntsec. Would you please try it, Egor? It then would be better, to insert /bin/sh as shell again in this entry, because this would be compatible to the standard behaviour. This also would be a good choice for the default /etc/group entry. Instead of using the dummy group `Everyone' which doesn't refer to any meaningful group, I suggest using the `Administrators' group (gid 544). We would get the groups native name with the call `LookupAccountSid (NULL, get_admin_sid (), ...)'! After Egor's test, I would then implement an according change to `grp.cc'. Regards, Corinna -- new mail address: mailto:corinna@vinschen.de From deo@logos-m.ru Wed Jun 9 02:49:00 1999 From: deo@logos-m.ru (Egor Duda) Date: Wed, 09 Jun 1999 02:49:00 -0000 Subject: default /etc/passwd contents References: <375D805A.90C9D21B@vinschen.de> Message-ID: <14566.990609@logos-m.ru> Hi! 9 ???????????????? 1999 Corinna Vinschen corinna@vinschen.de wrote: >> You can't get gid, because gid is only meaningful, if it's read from >> /etc/passwd. Remember: Outside of domains, no primary group exists. >> You only get name and uid but it should be possible, to use the >> administrators group (gid 544) as primary group in any case. Won't it give too much rights to this default user? CV> Umm, I thought about it once more. This may also work with ntsec. CV> Would you please try it, Egor? CV> It then would be better, to insert /bin/sh as shell again in this entry, CV> because this would be compatible to the standard behaviour. AFAIK, far more common practice is to assign /bin/nonexistent as a shell for most users, at least 80% of users on our unix hosts don't have a shell. or perhaps it should be controlled via environment variable CYGWIN_SHELL? CV> This also would be a good choice for the default /etc/group entry. CV> Instead of using the dummy group `Everyone' which doesn't refer CV> to any meaningful group, I suggest using the `Administrators' CV> group (gid 544). We would get the groups native name with the call CV> `LookupAccountSid (NULL, get_admin_sid (), ...)'! hmm. i think it will work under NT, however i think that we should give minimal rights to "dummy" user. Will it be so, if he will belong to "Administrators" group? Either way, under win95 there should be some default uid and gid. Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 From corinna@vinschen.de Wed Jun 9 11:17:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Wed, 09 Jun 1999 11:17:00 -0000 Subject: default /etc/passwd contents References: <375D805A.90C9D21B@vinschen.de> <17457.990609@logos-m.ru> Message-ID: <375EAE9D.909A96B3@vinschen.de> Egor Duda wrote: > > Hi! > > 9 ???????????????? 1999 Corinna Vinschen corinna@vinschen.de wrote: > > >> You can't get gid, because gid is only meaningful, if it's read from > >> /etc/passwd. Remember: Outside of domains, no primary group exists. > >> You only get name and uid but it should be possible, to use the > >> administrators group (gid 544) as primary group in any case. > > Won't it give too much rights to this default user? No, the rights of the user are not changed by this. It only has the effect, that the group permissions that are set e.g. on files via chmod are given to the admins group. If you would use e.g. `Guests' group, it has the (negativ) effect, that nearly everyone has rights on the files. This would be less secure than using `administrators', assuming that admins are less dangerous for system security ;-). > CV> It then would be better, to insert /bin/sh as shell again in this entry, > CV> because this would be compatible to the standard behaviour. > > AFAIK, far more common practice is to assign /bin/nonexistent as a > shell for most users, at least 80% of users on our unix hosts don't > have a shell. or perhaps it should be controlled via environment > variable CYGWIN_SHELL? Anyway, the default entry wouldn't let users login via `telnetd' or else, so the default shell is not of real interest. IMHO, we should avoid another DLL specific environment variables. In this case, it wouldn't make sense, too. > CV> This also would be a good choice for the default /etc/group entry. > CV> Instead of using the dummy group `Everyone' which doesn't refer > CV> to any meaningful group, I suggest using the `Administrators' > CV> group (gid 544). We would get the groups native name with the call > CV> `LookupAccountSid (NULL, get_admin_sid (), ...)'! > > hmm. i think it will work under NT, however i think that we should give > minimal rights to "dummy" user. Will it be so, if he will belong to > "Administrators" group? As aforementioned it wouldn't grant more rights to the user. It only would give the group rights to the admins group. But I'm thinking the `paranoid' way. If we are `relaxed' we may use the `Users' group (GID 545) or `Power Users' group (GID 547), too. And, once more, we must take their native names! > Either way, under win95 there should be some default uid and gid. Any funny number is ok :) Regards, Corinna From cgf@cygnus.com Wed Jun 9 14:46:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Wed, 09 Jun 1999 14:46:00 -0000 Subject: JIT debugging with gdb References: <375ec652.10516371@smtp.netzero.net> <375ec652.10516371@smtp.netzero.net> Message-ID: <19990609174733.A23582@cygnus.com> I'm not sure why you'd want to use gdb in this fashion since it can't currently use symbol information from VC++ programs. Also, I *really* don't want to have discussions in cygwin-developers that are cross-pollinated from cygwin so I've removed cygwin@sourceware.cygnus.com from the To:. cgf On Wed, Jun 09, 1999 at 08:07:20PM +0000, John R Hanson wrote: >Following is a patch to add basic support to the cvs gdb >for JIT debugging on win95 and NT 4. > >Currently only works for vc++ and mingw32 .exe's cause >cygwin doesn't let the system handle exceptions. >(easy fix is just to return 1 in .../winsup/exceptions.cc->handel_exceptions() > instead of printing out those oh so useful *.core files :) > >TODO (for someone else ;) get executable name from pid and load it. >WORKAROUND use >add-symbol-file filename.exe 0x401000 >at the (gdb) prompt. > >Could someone please check if this works for >98 and 2000? > >REGEDIT4 > >[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\aedebug] >"Auto"="0" >"Debugger"="d:/usr/H-i586~1/bin/gdb -c %#x -Event-HANDLE %ld" > > > >--- ./win32-nat.c 1999/05/30 10:17:24 1.2 >+++ ./win32-nat.c 1999/06/04 11:22:14 >@@ -119,6 +119,8 @@ > static int debug_memory = 0; /* show target memory accesses */ > static int debug_exceptions = 0; /* show target exceptions */ > >+HANDLE notify_attach = 0; /* JIT event handle from command line to notify kernel we are attached */ >+ > /* This vector maps GDB's idea of a register's number into an address > in the win32 exception context vector. > >@@ -639,6 +641,8 @@ > case EXCEPTION_BREAKPOINT: > DEBUG_EXCEPT (("gdb: Target exception BREAKPOINT at 0x%08x\n", > current_event.u.Exception.ExceptionRecord.ExceptionAddress)); >+ if (current_event.u.Exception.dwFirstChance && notify_attach){ th->context.Eip = (DWORD)current_event.u.Exception.ExceptionRecord.ExceptionAddress + 1; SetThreadContext(th->h, &th->context); } >+ if (notify_attach && (exception_count == 1) && !(GetVersion() < 0x80000000) && !SetEvent(notify_attach)) DEBUG_EXCEPT (("gdb: could not notify windows of attach\n")); > ourstatus->value.sig = TARGET_SIGNAL_TRAP; > break; > case DBG_CONTROL_C: >@@ -712,6 +716,7 @@ > char *p; > thread_info *th; > int sig; >+ int except_result; > > if (debug_event) > { >@@ -738,6 +743,8 @@ > current_event.dwProcessId, current_event.dwThreadId, > "EXIT_THREAD_DEBUG_EVENT")); > child_delete_thread (current_event.dwThreadId); >+ if (notify_attach && (GetVersion() < 0x80000000) && SetEvent(notify_attach)) notify_attach = 0; >+ else if (notify_attach && (GetVersion() < 0x80000000)) {DEBUG_EVENTS (("gdb: could not notify NT of attach event. HANDLE=%\n", notify_attach)); notify_attach = 0;} > break; > > case CREATE_PROCESS_DEBUG_EVENT: >@@ -780,8 +787,11 @@ > DEBUG_EVENTS (("gdb: kernel event for pid=%d tid=%d code=%s)\n", > current_event.dwProcessId, current_event.dwThreadId, > "EXCEPTION_DEBUG_EVENT")); >- if (handle_exception (ourstatus)) >- return current_event.dwThreadId; >+ if ((except_result = handle_exception (ourstatus)) && ((ourstatus->value.sig != TARGET_SIGNAL_TRAP) || !notify_attach)) >+ return current_event.dwThreadId; /* not a trap or we are not JIT attaching */ >+#define DBG_EXCEPTION_HANDLED ((DWORD)0x00010001L) >+ else if (except_result && (GetVersion() < 0x80000000)) { continue_status = DBG_EXCEPTION_HANDLED; break; /* attaching NT */ } >+ else if (except_result && (exception_count == 2)){notify_attach = 0;break; /* 9x fall through for the 1st one */} > continue_status = DBG_EXCEPTION_NOT_HANDLED; > break; > >--- ./config/i386/xm-cygwin.h 1999/05/31 14:41:24 1.1 >+++ ./config/i386/xm-cygwin.h 1999/06/04 11:09:58 >@@ -33,3 +33,7 @@ > > #define HAVE_SIGSETMASK 0 > >+extern void *notify_attach; /* kernel supplied event handle to notify it of JIT attach */ >+#define ADDITIONAL_OPTIONS {"Event-HANDLE", required_argument, 0, 1004}, >+#define ADDITIONAL_OPTION_CASES case 1004: notify_attach = (HANDLE)atoi(optarg); break; >+#define ADDITIONAL_OPTION_HELP " -Event-HANDLE HANDLE handle to signal the kernel we have attached for JIT.\n" From cgf@cygnus.com Thu Jun 10 19:48:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Thu, 10 Jun 1999 19:48:00 -0000 Subject: No more .core files Message-ID: <19990610224952.A26687@cygnus.com> I just changed the name of the files produced by cygwin from something.core to something.stackdump. Hopefully this will help minimize some confusion and pave the way for true core files in the future -- once I finally get the assignment form from Egor. -- cgf@cygnus.com http://www.cygnus.com/ From corinna@vinschen.de Fri Jun 11 01:00:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Fri, 11 Jun 1999 01:00:00 -0000 Subject: No more .core files References: <19990610224952.A26687@cygnus.com> Message-ID: <3760C1E0.459A3D41@vinschen.de> Chris Faylor wrote: > > I just changed the name of the files produced by cygwin from > something.core to something.stackdump. Hopefully this will help > minimize some confusion and pave the way for true core files in the > future -- once I finally get the assignment form from Egor. The something.stackdump files will die then? Good news. Corinna From cgf@cygnus.com Fri Jun 11 08:16:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Fri, 11 Jun 1999 08:16:00 -0000 Subject: No more .core files References: <19990610224952.A26687@cygnus.com> <3760C1E0.459A3D41@vinschen.de> <3760C1E0.459A3D41@vinschen.de> Message-ID: <19990611111702.B795@cygnus.com> On Fri, Jun 11, 1999 at 09:59:28AM +0200, Corinna Vinschen wrote: >Chris Faylor wrote: >> >> I just changed the name of the files produced by cygwin from >> something.core to something.stackdump. Hopefully this will help >> minimize some confusion and pave the way for true core files in the >> future -- once I finally get the assignment form from Egor. > >The something.stackdump files will die then? Good news. Only if someone has selected that they want to have core files. I think that the stackdump files are marginally useful. They allow me to say "It's not cygwin's fault." pretty quickly by inspecting the address where a fault occurred. cgf From corinna@vinschen.de Fri Jun 11 13:14:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Fri, 11 Jun 1999 13:14:00 -0000 Subject: No more .core files References: <19990610224952.A26687@cygnus.com> <3760C1E0.459A3D41@vinschen.de> <19990611111702.B795@cygnus.com> Message-ID: <37616E1F.3D6D822B@vinschen.de> Chris Faylor wrote: > > On Fri, Jun 11, 1999 at 09:59:28AM +0200, Corinna Vinschen wrote: > >Chris Faylor wrote: > >> > >> I just changed the name of the files produced by cygwin from > >> something.core to something.stackdump. Hopefully this will help > >> minimize some confusion and pave the way for true core files in the > >> future -- once I finally get the assignment form from Egor. > > > >The something.stackdump files will die then? Good news. > > Only if someone has selected that they want to have core files. > > I think that the stackdump files are marginally useful. They allow > me to say "It's not cygwin's fault." pretty quickly by inspecting the > address where a fault occurred. I understand. Assuming, Egor has signed, shouldn't this behaviour be controlled by the CYGWIN variable e.g (no)core (no)dump? I think, this would be useful and convenient options. Corinna From earnie_boyd@yahoo.com Fri Jun 11 16:40:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Fri, 11 Jun 1999 16:40:00 -0000 Subject: No more .core files Message-ID: <19990611234044.2389.rocketmail@send205.yahoomail.com> --- Corinna Vinschen wrote: > Chris Faylor wrote: > > > > On Fri, Jun 11, 1999 at 09:59:28AM +0200, Corinna Vinschen wrote: > > >Chris Faylor wrote: > > >> > > >> I just changed the name of the files produced by cygwin from > > >> something.core to something.stackdump. Hopefully this will help > > >> minimize some confusion and pave the way for true core files in the > > >> future -- once I finally get the assignment form from Egor. > > > > > >The something.stackdump files will die then? Good news. > > > > Only if someone has selected that they want to have core files. > > > > I think that the stackdump files are marginally useful. They allow > > me to say "It's not cygwin's fault." pretty quickly by inspecting the > > address where a fault occurred. > > I understand. > > Assuming, Egor has signed, shouldn't this behaviour be controlled by > the CYGWIN variable e.g (no)core (no)dump? > > I think, this would be useful and convenient options. I agree. However, display it to stdout if nocore and nodump. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From corinna@vinschen.de Fri Jun 11 16:51:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Fri, 11 Jun 1999 16:51:00 -0000 Subject: No more .core files References: <19990611234044.2389.rocketmail@send205.yahoomail.com> Message-ID: <3761A0F0.2116A852@vinschen.de> Earnie Boyd wrote: > > --- Corinna Vinschen wrote: > > Assuming, Egor has signed, shouldn't this behaviour be controlled by > > the CYGWIN variable e.g (no)core (no)dump? > > > > I think, this would be useful and convenient options. > > I agree. However, display it to stdout if nocore and nodump. ^^^^^^ You mean stderr, do you? Then, only a short message should appear, e.g. only the words "Access violation". Corinna From earnie_boyd@yahoo.com Fri Jun 11 18:42:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Fri, 11 Jun 1999 18:42:00 -0000 Subject: No more .core files Message-ID: <19990612014305.27003.rocketmail@web601.yahoomail.com> --- Corinna Vinschen wrote: > Earnie Boyd wrote: > > > > --- Corinna Vinschen wrote: > > > Assuming, Egor has signed, shouldn't this behaviour be controlled by > > > the CYGWIN variable e.g (no)core (no)dump? > > > > > > I think, this would be useful and convenient options. > > > > I agree. However, display it to stdout if nocore and nodump. > ^^^^^^ > You mean stderr, do you? Yes, that would be appropriate. The brain gets slower as I get older. ;^) > > Then, only a short message should appear, e.g. only the words > "Access violation". No the stackdump. It is often useful and as a single user I don't want files cluttering up the disk unless I need them to; but, I still would like to see the information. Ok. To keep everybody happy how about [no]dump[=display] or similar so that 1) CYGWIN=dump : will create the file.exe.dump 2) CYGWIN=dump=display : will create the file.exe.dump and display to stderr. 3) CYGWIN=nodump : don't create the file and display "Access violation". 4) CYGWIN=nodump=display : don't create file.exe.dump but display to stderr. The default would be dump if nocore is set and nodump if core is set. The default for core should be TRUE. BTW: I just came to realize that it should be [no]stack[=display] instead of [no]dump[=display] as dump could refer to coredump or stackdump. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From corinna@vinschen.de Sat Jun 12 02:05:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Sat, 12 Jun 1999 02:05:00 -0000 Subject: fhandler patch Message-ID: <37622161.87D858A@vinschen.de> Hi! I've found an error in fhandler.cc. The method `fhandler::read' didn't return an error anymore if the `raw_read' method returns with -1! The patch is attached. Regards, Corinna ChangeLog: ========== Sat Jun 12 10:54:00 1999 Corinna Vinschen * fhandler.cc (fhandler_base::read): Returns correct value if raw_read fails. * fhandler_raw.cc: More trace output. * fhandler_floppy.cc: Ditto. * fhandler_tape.cc: Ditto. Index: fhandler.cc =================================================================== RCS file: /src/cvsroot/winsup-990602/fhandler.cc,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fhandler.cc --- fhandler.cc 1999/06/03 20:38:57 1.1.1.1 +++ fhandler.cc 1999/06/12 08:57:44 @@ -441,7 +441,7 @@ fhandler_base::read (void *in_ptr, size_ int chars_to_process = len ? raw_read (ptr, len) : 0; if (chars_to_process <= 0) - return ptr - (char *) in_ptr; + return chars_to_process; chars_to_process += in_len - len; Index: fhandler_floppy.cc =================================================================== RCS file: /src/cvsroot/winsup-990602/fhandler_floppy.cc,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fhandler_floppy.cc --- fhandler_floppy.cc 1999/06/03 20:38:58 1.1.1.1 +++ fhandler_floppy.cc 1999/06/12 08:29:15 @@ -21,13 +21,19 @@ details. */ int fhandler_dev_floppy::is_eom (int win_error) { - return win_error == ERROR_INVALID_PARAMETER; + int ret = (win_error == ERROR_INVALID_PARAMETER); + if (ret) + debug_printf ("end of medium"); + return ret; } int fhandler_dev_floppy::is_eof (int win_error) { - return 0; + int ret = 0; + if (ret) + debug_printf ("end of file"); + return ret; } fhandler_dev_floppy::fhandler_dev_floppy (const char *name, int unit) : fhandler_dev_raw (FH_FLOPPY, name, unit) Index: fhandler_raw.cc =================================================================== RCS file: /src/cvsroot/winsup-990602/fhandler_raw.cc,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fhandler_raw.cc --- fhandler_raw.cc 1999/06/03 20:38:58 1.1.1.1 +++ fhandler_raw.cc 1999/06/12 08:33:51 @@ -213,6 +213,7 @@ fhandler_dev_raw::raw_read (void *ptr, s get_name (), ret); if (!is_eof (ret) && !is_eom (ret)) { + debug_printf ("return -1, set errno to EACCES"); set_errno (EACCES); return -1; } @@ -226,6 +227,7 @@ fhandler_dev_raw::raw_read (void *ptr, s { if (!bytes_read && is_eom (ret)) { + debug_printf ("return -1, set errno to ENOSPC"); set_errno (ENOSPC); return -1; } @@ -256,6 +258,7 @@ fhandler_dev_raw::raw_read (void *ptr, s get_name (), ret); if (!is_eof (ret) && !is_eom (ret)) { + debug_printf ("return -1, set errno to EACCES"); set_errno (EACCES); return -1; } @@ -268,6 +271,7 @@ fhandler_dev_raw::raw_read (void *ptr, s } else if (is_eom (ret)) { + debug_printf ("return -1, set errno to ENOSPC"); set_errno (ENOSPC); return -1; } Index: fhandler_tape.cc =================================================================== RCS file: /src/cvsroot/winsup-990602/fhandler_tape.cc,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fhandler_tape.cc --- fhandler_tape.cc 1999/06/03 20:38:58 1.1.1.1 +++ fhandler_tape.cc 1999/06/12 08:28:02 @@ -31,16 +31,22 @@ fhandler_dev_tape::clear (void) int fhandler_dev_tape::is_eom (int win_error) { - return ((win_error == ERROR_END_OF_MEDIA) + int ret = ((win_error == ERROR_END_OF_MEDIA) || (win_error == ERROR_EOM_OVERFLOW) || (win_error == ERROR_NO_DATA_DETECTED)); + if (ret) + debug_printf ("end of medium"); + return ret; } int fhandler_dev_tape::is_eof (int win_error) { - return ((win_error == ERROR_FILEMARK_DETECTED) + int ret = ((win_error == ERROR_FILEMARK_DETECTED) || (win_error == ERROR_SETMARK_DETECTED)); + if (ret) + debug_printf ("end of file"); + return ret; } fhandler_dev_tape::fhandler_dev_tape (const char *name, int unit) : fhandler_dev_raw (FH_TAPE, name, unit) From cgf@cygnus.com Sat Jun 12 09:18:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Sat, 12 Jun 1999 09:18:00 -0000 Subject: fhandler patch References: <37622161.87D858A@vinschen.de> <37622161.87D858A@vinschen.de> Message-ID: <19990612121928.B776@cygnus.com> Applied. Thanks. -chris On Sat, Jun 12, 1999 at 10:59:13AM +0200, Corinna Vinschen wrote: >I've found an error in fhandler.cc. The method `fhandler::read' didn't >return an error anymore if the `raw_read' method returns with -1! > >The patch is attached. From fujieda@jaist.ac.jp Sat Jun 12 11:08:00 1999 From: fujieda@jaist.ac.jp (Kazuhiro Fujieda) Date: Sat, 12 Jun 1999 11:08:00 -0000 Subject: duplicate inode number Message-ID: I reported this problem and the patch resolving it once, but there has been no response. So I try to explain it more concretely. As reported in the cygwin mailing list, `mv' sometime complains completely different files are the same file. Because these files have the same inode number. For example, $ touch 1 2 3 4 5 $ mv 1 2 mv: `1' and `2' are the same file $ ls -i 1447 1 1447 2 1445 3 1445 4 1447 5 This can be observed on Win9x in the snapshots since 12 Feb when the following changes are made. Fri Feb 12 13:17:49 1999 Corinna Vinschen * fhandler.cc (fhandler_disk_file::fstat): Handles directories, returns unique i-node number. * syscalls.cc (stat_worker): On WinNT, stat_worker calls fhandler_disk_file::fstat for directories, too. ____ | AIST Kazuhiro Fujieda | HOKURIKU School of Information Science o_/ 1990 Japan Advanced Institute of Science and Technology From corinna@vinschen.de Sat Jun 12 14:00:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Sat, 12 Jun 1999 14:00:00 -0000 Subject: duplicate inode number References: Message-ID: <3762C2DB.E7F2AC90@vinschen.de> Kazuhiro Fujieda wrote: > > I reported this problem and the patch resolving it once, but there > has been no response. So I try to explain it more concretely. > > As reported in the cygwin mailing list, `mv' sometime complains > completely different files are the same file. Because these files > have the same inode number. > > For example, > > $ touch 1 2 3 4 5 > $ mv 1 2 > mv: `1' and `2' are the same file > $ ls -i > 1447 1 1447 2 1445 3 1445 4 1447 5 > > This can be observed on Win9x in the snapshots since 12 Feb when the > following changes are made. > > Fri Feb 12 13:17:49 1999 Corinna Vinschen > > * fhandler.cc (fhandler_disk_file::fstat): Handles directories, > returns unique i-node number. > * syscalls.cc (stat_worker): On WinNT, stat_worker calls > fhandler_disk_file::fstat for directories, too. Ok, I have patched it to old behaviour for 9X. Thanks, Corinna ChangeLog: ========== Sat Jun 12 22:22:00 1999 Corinna Vinschen * fhandler.cc (fhandler_disk_file::fstat): For 9X, i-node numbers computed via `get_namehash' again. Index: fhandler.cc =================================================================== RCS file: /src/cvsroot/winsup-990602/fhandler.cc,v retrieving revision 1.2 diff -u -p -r1.2 fhandler.cc --- fhandler.cc 1999/06/12 20:07:08 1.2 +++ fhandler.cc 1999/06/12 20:20:34 @@ -882,7 +882,10 @@ fhandler_disk_file::fstat (struct stat * buf->st_nlink = local.nNumberOfLinks; buf->st_dev = local.dwVolumeSerialNumber; buf->st_size = local.nFileSizeLow; - buf->st_ino = local.nFileIndexHigh | local.nFileIndexLow; + if (os_being_run != winNT) + buf->st_ino = local.nFileIndexLow ^ get_namehash (); + else + buf->st_ino = local.nFileIndexHigh | local.nFileIndexLow; buf->st_blksize = S_BLKSIZE; buf->st_blocks = (buf->st_size + S_BLKSIZE-1) / S_BLKSIZE; buf->st_uid = get_file_owner (get_win32_name ()); From cgf@cygnus.com Sat Jun 12 14:04:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Sat, 12 Jun 1999 14:04:00 -0000 Subject: duplicate inode number References: <3762C2DB.E7F2AC90@vinschen.de> <3762C2DB.E7F2AC90@vinschen.de> Message-ID: <19990612170514.A31962@cygnus.com> On Sat, Jun 12, 1999 at 10:28:11PM +0200, Corinna Vinschen wrote: >> Fri Feb 12 13:17:49 1999 Corinna Vinschen >> >> * fhandler.cc (fhandler_disk_file::fstat): Handles directories, >> returns unique i-node number. >> * syscalls.cc (stat_worker): On WinNT, stat_worker calls >> fhandler_disk_file::fstat for directories, too. > >Ok, I have patched it to old behaviour for 9X. Actually Kazuhiro already submitted a patch which did this and cleaned up the stat code a little. Could you repost it, Kazuhiro? cgf From fujieda@jaist.ac.jp Sat Jun 12 16:38:00 1999 From: fujieda@jaist.ac.jp (Kazuhiro Fujieda) Date: Sat, 12 Jun 1999 16:38:00 -0000 Subject: Repost: different files have the same i-node number. Message-ID: In recent snapshots, different files sometime have the same i-node number on Win9x. This is caused by the following code in fhandler.cc. 882: buf->st_ino = local.nFileIndexHigh | local.nFileIndexLow; This value isn't quiet unique on Win9x, so i-node should be based on a hash number like the past snapshots on Win9x. --- fhandler.cc- Thu Mar 25 12:22:46 1999 +++ fhandler.cc Wed May 19 17:28:14 1999 @@ -879,7 +879,11 @@ fhandler_disk_file::fstat (struct stat * buf->st_nlink = local.nNumberOfLinks; buf->st_dev = local.dwVolumeSerialNumber; buf->st_size = local.nFileSizeLow; - buf->st_ino = local.nFileIndexHigh | local.nFileIndexLow; + if (os_being_run == winNT) + /* This is not unique on Win9x */ + buf->st_ino = local.nFileIndexHigh | local.nFileIndexLow; + else + buf->st_ino = local.nFileIndexLow ^ get_namehash (); buf->st_blksize = S_BLKSIZE; buf->st_blocks = (buf->st_size + S_BLKSIZE-1) / S_BLKSIZE; buf->st_uid = get_file_owner (get_win32_name ()); By the way, conditional branches about file types in stat_worker() are a little tedious and not intuitive. They can be more simple. --- syscalls.cc- Wed Mar 10 07:30:18 1999 +++ syscalls.cc Wed May 19 17:34:08 1999 @@ -1215,24 +1215,7 @@ stat_worker (const char *caller, const c drive[0] = win32_name[0]; UINT dtype; - if (os_being_run == winNT - && (!(atts & FILE_ATTRIBUTE_DIRECTORY) - || ((dtype = GetDriveType (drive)) != DRIVE_NO_ROOT_DIR - && dtype != DRIVE_REMOTE - && dtype != DRIVE_UNKNOWN))) - { - fhandler_disk_file fh (NULL); - - if (fh.open (real_path, O_RDONLY | O_BINARY | O_DIROPEN | - (nofollow ? O_NOSYMLINK : 0), 0)) - { - res = fh.fstat (buf); - fh.close (); - if (atts != -1 && (atts & FILE_ATTRIBUTE_DIRECTORY)) - buf->st_nlink = num_entries (win32_name); - } - } - else if (atts == -1 || !(atts & FILE_ATTRIBUTE_DIRECTORY)) + if (atts == -1 || !(atts & FILE_ATTRIBUTE_DIRECTORY)) { fhandler_disk_file fh (NULL); @@ -1242,6 +1225,21 @@ stat_worker (const char *caller, const c res = fh.fstat (buf); fh.close (); } + } + else if (os_being_run == winNT + && ((dtype = GetDriveType (drive)) != DRIVE_NO_ROOT_DIR + && dtype != DRIVE_REMOTE + && dtype != DRIVE_UNKNOWN)) + { + fhandler_disk_file fh (NULL); + + if (fh.open (real_path, O_RDONLY | O_BINARY | O_DIROPEN | + (nofollow ? O_NOSYMLINK : 0), 0)) + { + res = fh.fstat (buf); + fh.close (); + buf->st_nlink = num_entries (win32_name); + } } else { ____ | AIST Kazuhiro Fujieda | HOKURIKU School of Information Science o_/ 1990 Japan Advanced Institute of Science and Technology From cgf@cygnus.com Sat Jun 12 18:05:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Sat, 12 Jun 1999 18:05:00 -0000 Subject: strace improvements Message-ID: <19990612210604.A9057@cygnus.com> I felt ambitious today so I've taken the time to change cygwin's strace interface. I've gotten rid of the environment variable interface in favor of control from an external program. So, to get an strace dump you now do something like: strace -m1 -o/tmp/strace.out ls The strace program will grab OutputDebugString information (this is new) from the child and send it to the file /tmp/strace.out. Here are the current options: Option Description f Strace all children m Supply strace mask (1 is the default) o fn Specify output filename (default stdout) t Translate Win32 errors to text mode. I haven't checked this in yet, nor have I checked it on Windows 95. There is also a gotcha in that strace is currently a cygwin program. I don't think it has to be a cygwin program. It was just easier to write that way. Does this sound like the correct way to go with this? -chris From earnie_boyd@yahoo.com Sat Jun 12 20:55:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Sat, 12 Jun 1999 20:55:00 -0000 Subject: duplicate inode number Message-ID: <19990613035547.8465.rocketmail@web113.yahoomail.com> --- Kazuhiro Fujieda wrote: > I reported this problem and the patch resolving it once, but there > has been no response. So I try to explain it more concretely. > > As reported in the cygwin mailing list, `mv' sometime complains > completely different files are the same file. Because these files > have the same inode number. > > For example, > > $ touch 1 2 3 4 5 > $ mv 1 2 > mv: `1' and `2' are the same file > $ ls -i > 1447 1 1447 2 1445 3 1445 4 1447 5 > > This can be observed on Win9x in the snapshots since 12 Feb when the > following changes are made. > > Fri Feb 12 13:17:49 1999 Corinna Vinschen > > * fhandler.cc (fhandler_disk_file::fstat): Handles directories, > returns unique i-node number. The MS documentation says that the numbers could indeed be the same for different files if you open/fstat/close then open/fstat/close. The purpose of MS's fileid number is so that you can check to see if you have the same file open on more than one fd in the same process. The fileid number is not unique to the file but is unique to the process. I could open the file in one process and get fileid 1447 and in a different process open the same file and get fileid 1449 as examples. I too suggest the change be reverted before the release of B21. This I believe was tested on WinNT where it seems to work. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From cgf@cygnus.com Mon Jun 14 16:09:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Mon, 14 Jun 1999 16:09:00 -0000 Subject: Tonight's snapshot Message-ID: <19990614191043.A3693@cygnus.com> - I've added the strace stuff to our repository so it should show up tonight. - I've fixed a bug in tty handling. - I've added Corinna's fixes for the problems that Kazuhiro Fujieda had noted earlier. Apologies for waiting so long to do this. I didn't realize that the problems were as serious as they appeared to be. - I went with the spirit of Kazuhiro Fujieda's changes to stat_worker and simplified some of the code there. I hope that the snapshots are getting close to release quality. Please give them a try and let me know. -- cgf@cygnus.com http://www.cygnus.com/ From khan@xraylith.wisc.EDU Mon Jun 14 16:23:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Mon, 14 Jun 1999 16:23:00 -0000 Subject: Tonight's snapshot References: <19990614191043.A3693@cygnus.com> Message-ID: <199906142216.RAA18739@mercury.xraylith.wisc.edu> Chris Faylor writes: > > I hope that the snapshots are getting close to release quality. > Please give them a try and let me know. > It would be nice if we could get rid of cygwin_non_cygwin_dll_entry@12 by next release! However, that will mean breaking binary compat, so may not be an option. Failing that, it really needs to be looked at to make sure we're doing everything needed there right now (ie., init' ing all the stuff that's needed for a Cygwin DLL loaded by non-cygwin app/DLL). Also, some test runs with gcc-2.95 pre-release snapshots will be quite useful. Oh, and if we are breaking binary compat, then we should take the opportunity to switch over to using vtable thunks. I'm not sure if/when I'll time to do either, so any takers? Regards, Mumit From cgf@cygnus.com Mon Jun 14 18:14:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Mon, 14 Jun 1999 18:14:00 -0000 Subject: Tonight's snapshot References: <19990614191043.A3693@cygnus.com> <199906142216.RAA18739@mercury.xraylith.wisc.edu> <199906142216.RAA18739@mercury.xraylith.wisc.edu> Message-ID: <19990614211537.D3801@cygnus.com> I don't think I want to break binary compatibility quite yet. I agree that it would be nice to ensure that things are working correctly. I'd be grateful to anyone who could look into this. cgf On Mon, Jun 14, 1999 at 05:16:21PM -0500, Mumit Khan wrote: >Chris Faylor writes: >> I hope that the snapshots are getting close to release quality. >> Please give them a try and let me know. > >It would be nice if we could get rid of cygwin_non_cygwin_dll_entry@12 >by next release! However, that will mean breaking binary compat, so >may not be an option. Failing that, it really needs to be looked at >to make sure we're doing everything needed there right now (ie., init' >ing all the stuff that's needed for a Cygwin DLL loaded by non-cygwin >app/DLL). > >Also, some test runs with gcc-2.95 pre-release snapshots will be quite >useful. > >Oh, and if we are breaking binary compat, then we should take the >opportunity to switch over to using vtable thunks. > >I'm not sure if/when I'll time to do either, so any takers? From earnie_boyd@yahoo.com Wed Jun 16 04:50:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Wed, 16 Jun 1999 04:50:00 -0000 Subject: cygdrive confusing (was Re: new cygwin.dll (was Re: Make problems)) Message-ID: <19990616115714.13831.rocketmail@web116.yahoomail.com> --- Chris Faylor wrote: > I'm not sure why you think this should be empty. The value of "cygdrive > prefix" is used for drives which do not have corresponding mount table > entries. That means if you want to access the foo directory on your q: > drive you use: > > /cygdrive/q/foo > I see much confusion about this getting ready to happen. Would it be wise to change "cygdrive" to "unmounted" which gives a description of what it's about? === YAWIA, Earnie Boyd < mailto:earnie_boyd@yahoo.com > Newbies, please visit < http://www.freeyellow.com/members5/gw32/index.html > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From cgf@cygnus.com Wed Jun 16 07:53:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Wed, 16 Jun 1999 07:53:00 -0000 Subject: cygdrive confusing (was Re: new cygwin.dll (was Re: Make problems)) References: <19990616115714.13831.rocketmail@web116.yahoomail.com> <19990616115714.13831.rocketmail@web116.yahoomail.com> Message-ID: <19990616105426.C895@cygnus.com> On Wed, Jun 16, 1999 at 04:57:14AM -0700, Earnie Boyd wrote: >--- Chris Faylor wrote: >> I'm not sure why you think this should be empty. The value of "cygdrive >> prefix" is used for drives which do not have corresponding mount table >> entries. That means if you want to access the foo directory on your q: >> drive you use: >> >> /cygdrive/q/foo >> > >I see much confusion about this getting ready to happen. Would it be wise to >change "cygdrive" to "unmounted" which gives a description of what it's about? You can do this if you want. Personally, I like "cygdrive" since that is more descriptive, and it is not an English word so it is unlikely to be used. Perhaps if I understood the confusion I would be more amenable to the proposal but I have to confess that I don't. cgf From earnie_boyd@yahoo.com Wed Jun 16 08:07:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Wed, 16 Jun 1999 08:07:00 -0000 Subject: cygdrive confusing (was Re: new cygwin.dll (was Re: Make problems)) Message-ID: <19990616150751.16557.rocketmail@web129.yahoomail.com> --- Chris Faylor wrote: > You can do this if you want. Personally, I like "cygdrive" since that is > more > descriptive, and it is not an English word so it is unlikely to be used. > I know I can change it. I was indicating changing the default. > Perhaps if I understood the confusion I would be more amenable to the > proposal > but I have to confess that I don't. The confusion comes from newness to the use of cygwin or newness to new options added and the failure to read. I'm making the suggestion in order to keep the list quiet about it and not suggesting anything about the correctness of terms. === YAWIA, Earnie Boyd < mailto:earnie_boyd@yahoo.com > Newbies, please visit < http://www.freeyellow.com/members5/gw32/index.html > (If you respond to the list, then please don't include me) _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From fujieda@jaist.ac.jp Wed Jun 16 09:16:00 1999 From: fujieda@jaist.ac.jp (Kazuhiro Fujieda) Date: Wed, 16 Jun 1999 09:16:00 -0000 Subject: strace improvements References: <19990612210604.A9057@cygnus.com> Message-ID: >>> On Sat, 12 Jun 1999 21:06:04 -0400 >>> Chris Faylor said: > I felt ambitious today so I've taken the time to change cygwin's > strace interface. > > I've gotten rid of the environment variable interface in favor of > control from an external program. So, to get an strace dump you > now do something like: > > strace -m1 -o/tmp/strace.out ls (snip) > I haven't checked this in yet, nor have I checked it on Windows 95. I tried this on Win95. It can work generally, but the target process behaves very very slowly in comparison with the old manner. And the `strace' command waits for about a minute before it terminates after all target processes terminated. ____ | AIST Kazuhiro Fujieda | HOKURIKU School of Information Science o_/ 1990 Japan Advanced Institute of Science and Technology From noer@cygnus.com Wed Jun 16 11:08:00 1999 From: noer@cygnus.com (Geoffrey Noer) Date: Wed, 16 Jun 1999 11:08:00 -0000 Subject: cygdrive confusing (was Re: new cygwin.dll (was Re: Make problems)) References: <19990616115714.13831.rocketmail@web116.yahoomail.com> <19990616115714.13831.rocketmail@web116.yahoomail.com> Message-ID: <19990616110822.B17431@cygnus.com> [...] > I see much confusion about this getting ready to happen. Would it be wise to > change "cygdrive" to "unmounted" which gives a description of what it's about? The problem with "unmounted" is that when an automount happens to cygdrive, there really is a mount created in the process. So by the time /unmounted/e would get used, "unmounted" would no longer be a correct description of the situation. -- Geoffrey Noer Email: noer@cygnus.com Cygnus Solutions From cgf@cygnus.com Wed Jun 16 11:18:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Wed, 16 Jun 1999 11:18:00 -0000 Subject: cygdrive confusing (was Re: new cygwin.dll (was Re: Make problems)) References: <19990616115714.13831.rocketmail@web116.yahoomail.com> <19990616110822.B17431@cygnus.com> <19990616110822.B17431@cygnus.com> Message-ID: <19990616141852.B1197@cygnus.com> On Wed, Jun 16, 1999 at 11:08:22AM -0700, Geoffrey Noer wrote: >[...] >> I see much confusion about this getting ready to happen. Would it be wise to >> change "cygdrive" to "unmounted" which gives a description of what it's about? > >The problem with "unmounted" is that when an automount happens to >cygdrive, there really is a mount created in the process. So by the >time /unmounted/e would get used, "unmounted" would no longer be a >correct description of the situation. I've actually changed later snapshots so that these do not show up in the mount table. /cygdrive is now always usable as a default prefix for drives even for drives that have a mount associated with them. cgf From khan@xraylith.wisc.EDU Wed Jun 16 11:22:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Wed, 16 Jun 1999 11:22:00 -0000 Subject: cygdrive confusing (was Re: new cygwin.dll (was Re: Make problems)) References: <19990616141852.B1197@cygnus.com> Message-ID: <199906161715.MAA27965@mercury.xraylith.wisc.edu> Chris Faylor writes: > > I've actually changed later snapshots so that these do not show up in > the mount table. /cygdrive is now always usable as a default prefix for > drives even for drives that have a mount associated with them. > This seems like the most reasonable approach to me, and one that minimizes surprises, which is always a good thing. Thanks for the change. Regards, Mumit From noer@cygnus.com Wed Jun 16 11:25:00 1999 From: noer@cygnus.com (Geoffrey Noer) Date: Wed, 16 Jun 1999 11:25:00 -0000 Subject: cygdrive confusing (was Re: new cygwin.dll (was Re: Make problems)) References: <19990616115714.13831.rocketmail@web116.yahoomail.com> <19990616110822.B17431@cygnus.com> <19990616141852.B1197@cygnus.com> <19990616141852.B1197@cygnus.com> Message-ID: <19990616112509.A17478@cygnus.com> On Wed, Jun 16, 1999, Chris Faylor wrote: [...] > I've actually changed later snapshots so that these do not show up in > the mount table. /cygdrive is now always usable as a default prefix for > drives even for drives that have a mount associated with them. OK, never mind then. :-) Does this bring us closer to being able to axe /// then I hope? -- Geoffrey Noer Email: noer@cygnus.com Cygnus Solutions From cgf@cygnus.com Wed Jun 16 11:27:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Wed, 16 Jun 1999 11:27:00 -0000 Subject: cygdrive confusing (was Re: new cygwin.dll (was Re: Make problems)) References: <19990616115714.13831.rocketmail@web116.yahoomail.com> <19990616110822.B17431@cygnus.com> <19990616141852.B1197@cygnus.com> <19990616112509.A17478@cygnus.com> <19990616112509.A17478@cygnus.com> Message-ID: <19990616142806.A1305@cygnus.com> On Wed, Jun 16, 1999 at 11:25:09AM -0700, Geoffrey Noer wrote: >On Wed, Jun 16, 1999, Chris Faylor wrote: >[...] >> I've actually changed later snapshots so that these do not show up in >> the mount table. /cygdrive is now always usable as a default prefix for >> drives even for drives that have a mount associated with them. > >OK, never mind then. :-) > >Does this bring us closer to being able to axe /// then >I hope? I'd like to but I think we should probably wait for a long time before removing it entirely. It is only recognized now. As you know, cygwin will never generate a //x path nowadays. cgf From cgf@cygnus.com Wed Jun 16 11:30:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Wed, 16 Jun 1999 11:30:00 -0000 Subject: cygdrive confusing (was Re: new cygwin.dll (was Re: Make problems)) References: <19990616141852.B1197@cygnus.com> <199906161715.MAA27965@mercury.xraylith.wisc.edu> <199906161715.MAA27965@mercury.xraylith.wisc.edu> Message-ID: <19990616143142.A1329@cygnus.com> On Wed, Jun 16, 1999 at 12:15:41PM -0500, Mumit Khan wrote: >Chris Faylor writes: >> I've actually changed later snapshots so that these do not show up in >> the mount table. /cygdrive is now always usable as a default prefix for >> drives even for drives that have a mount associated with them. >> > >This seems like the most reasonable approach to me, and one that minimizes >surprises, which is always a good thing. > >Thanks for the change. You're welcome. I'm now glad this thread was started, actually, because I'd meant to announce this change and get feedback on it but... I forgot. I know. I know. I hate to disillusion people. I'm actually not as inflalible as I seme. cgf From cgf@cygnus.com Wed Jun 16 11:49:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Wed, 16 Jun 1999 11:49:00 -0000 Subject: Something is rotten in recent snapshots Message-ID: <19990616145002.A1955@cygnus.com> There is some kind of memory corruption in recent snapshots. I'm tracking down the cause now. Unless you want to track down the problem for me, you'd all probably be well-advised not to use any snapshot from the last week or so. Just in case anyone cares, the problem I see is that an attempt to close all of the open handles in the spawn_guts() function uncovers the fact that the heap is corrupted. I'm trying to find out where the corruption occurs now. I don't suppose that Electric Fence has been ported to cygwin? -- cgf@cygnus.com http://www.cygnus.com/ From TYann@vet.com.au Wed Jun 16 15:39:00 1999 From: TYann@vet.com.au (Trevor Yann) Date: Wed, 16 Jun 1999 15:39:00 -0000 Subject: Something is rotten in recent snapshots References: <19990616145002.A1955@cygnus.com> Message-ID: <376827BA.F8C0FF40@vet.com.au> There is something like Electric Fence for Windows. It is called HeapCheck: http://www.image.ece.ntua.gr/~ttsiod/HeapCheck.html I haven't tried to used it with Cygwin. Chris Faylor wrote: > > There is some kind of memory corruption in recent snapshots. I'm > tracking down the cause now. Unless you want to track down the problem > for me, you'd all probably be well-advised not to use any snapshot from > the last week or so. > > Just in case anyone cares, the problem I see is that an attempt to close > all of the open handles in the spawn_guts() function uncovers the fact > that the heap is corrupted. I'm trying to find out where the corruption > occurs now. > > I don't suppose that Electric Fence has been ported to cygwin? > > -- > cgf@cygnus.com > http://www.cygnus.com/ From deo@logos-m.ru Thu Jun 17 12:08:00 1999 From: deo@logos-m.ru (Egor Duda) Date: Thu, 17 Jun 1999 12:08:00 -0000 Subject: default /etc/passwd contents References: <375D805A.90C9D21B@vinschen.de> Message-ID: <3955.990617@logos-m.ru> Hi! 9 June 1999 Corinna Vinschen wrote: >> You can't get gid, because gid is only meaningful, if it's read from >> /etc/passwd. Remember: Outside of domains, no primary group exists. >> You only get name and uid but it should be possible, to use the >> administrators group (gid 544) as primary group in any case. CV> Umm, I thought about it once more. This may also work with ntsec. CV> Would you please try it, Egor? it seems to work ok under nt with ntsec. Either when logged in as a member of "administrators" group or as ordinary user. Alas, i have no '95 or '98 boxes around to check it up there. ssh, wget and others works just fine on machines without cygwin installed, and don't complain that "We don't know who are you, so go away." CV> This also would be a good choice for the default /etc/group entry. CV> Instead of using the dummy group `Everyone' which doesn't refer CV> to any meaningful group, I suggest using the `Administrators' CV> group (gid 544). We would get the groups native name with the call CV> `LookupAccountSid (NULL, get_admin_sid (), ...)'! A patch against snapshot-06-14-1999 is attached. Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 default_etc_passwd.diff.gz From khan@xraylith.wisc.EDU Thu Jun 17 23:32:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Thu, 17 Jun 1999 23:32:00 -0000 Subject: Something is rotten in recent snapshots References: <376827BA.F8C0FF40@vet.com.au> Message-ID: <199906180632.BAA30972@mercury.xraylith.wisc.edu> Trevor Yann writes: > There is something like Electric Fence for Windows. It is called > HeapCheck: > http://www.image.ece.ntua.gr/~ttsiod/HeapCheck.html Thanks for the pointer. I had forgotten about this package. > I haven't tried to used it with Cygwin. It should in theory work with user-code, but it looks a bit tricky if you want to debug the DLL itself. From a quick look, one would need to deal with the export_malloc thing. I'm planning to spend a bit time this weekend looking into it. Too bad one can't substitute functions in Win32 DLL on the fly as (easily as) on ELF. Regards, Mumit From cgf@cygnus.com Fri Jun 18 12:54:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Fri, 18 Jun 1999 12:54:00 -0000 Subject: Something is rotten in recent snapshots References: <19990616145002.A1955@cygnus.com> <376827BA.F8C0FF40@vet.com.au> <376827BA.F8C0FF40@vet.com.au> Message-ID: <19990618155530.A2585@cygnus.com> On Thu, Jun 17, 1999 at 08:39:54AM +1000, Trevor Yann wrote: >There is something like Electric Fence for Windows. It is called >HeapCheck: > http://www.image.ece.ntua.gr/~ttsiod/HeapCheck.html > >I haven't tried to used it with Cygwin. Thanks for the pointer. It looked really promising so I spent a little while hacking it up to work with cygwin. I just realized that this scheme won't work with cygwin's fork mechanism. Bleah. Maybe it's time to rewrite fork again. Yeah that's the ticket... cgf From cgf@cygnus.com Mon Jun 21 21:10:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Mon, 21 Jun 1999 21:10:00 -0000 Subject: Massive checkin but still no memory corruption fix Message-ID: <19990622001057.A23916@cygnus.com> I made a lot of changes that will be reflected in the recent snapshot but I am still seeing occasional memory corruption. It is really sporadic and difficult to track down. This is what I've fixed: 1) a long standing "wait_subproc: wait failed, nchildren..." error. 2) stopped looping if there's an error on exit. 3) argument passing in #! scripts (e.g. #!/bin/sh -x) 4) don't attempt to use ntsec on drives which do not support it. 5) run strace program at higher priority for slight speed improvement. I've also added the pseudo-JIT debugging from Egor Dada, although I wouldn't recommend using quite yet. It has a tendency to invoke itself a little aggressively. It obviously needs to be a little more integrated with gdb. -- cgf@cygnus.com http://www.cygnus.com/ From cgf@cygnus.com Mon Jun 21 21:11:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Mon, 21 Jun 1999 21:11:00 -0000 Subject: Massive checkin but still no memory corruption fix References: <19990622001057.A23916@cygnus.com> <19990622001057.A23916@cygnus.com> Message-ID: <19990622001240.A27341@cygnus.com> On Tue, Jun 22, 1999 at 12:10:57AM -0400, cgf wrote: >I made a lot of changes that will be reflected in the recent snapshot but >I am still seeing occasional memory corruption. It is really sporadic >and difficult to track down. > >This is what I've fixed: >1) a long standing "wait_subproc: wait failed, nchildren..." error. >2) stopped looping if there's an error on exit. >3) argument passing in #! scripts (e.g. #!/bin/sh -x) >4) don't attempt to use ntsec on drives which do not support it. >5) run strace program at higher priority for slight speed improvement. 6) Revert scrolling code to (almost) old behavior. The April 17 changes just caused too many problems. I think that scroll regions are broken again, now, if anyone cares. cgf From bettini@gdn.dsi.unifi.it Mon Jun 21 23:28:00 1999 From: bettini@gdn.dsi.unifi.it (Lorenzo Bettini) Date: Mon, 21 Jun 1999 23:28:00 -0000 Subject: DLL Message-ID: <376F1F7F.4F6AAD09@gdn.dsi.unifi.it> Hi I've just installed versione 2 under win98... I'd like to create an exe that doesn't need the dll: actually I'm just using bison and flex and I'm not using any Unix feature... is that possible? thanx in advance Lorenzo -- +-----------------------------------------------------+ | Lorenzo Bettini ICQ# lbetto, 16080134 | | PhD student in Informatica (Computer Science) | | Florence - Italy | | Home Page : http://w3.newnet.it/bettini | | http://infostud.dsi.unifi.it/~bettini | | Mail Home : lorenzo.bettini@penteres.it | | Mail University : bettini@infostud.dsi.unifi.it | | http://www.mokabyte.it Java on line journal | | http://rap.dsi.unifi.it/xklaim XKlaim language | +-----------------------------------------------------+ From rdparker@butlermfg.org Tue Jun 22 07:45:00 1999 From: rdparker@butlermfg.org (Parker, Ron) Date: Tue, 22 Jun 1999 07:45:00 -0000 Subject: DLL Message-ID: <6947.930062731.0@NO-ID-FOUND.mhonarc.com> Not with cygwin. It must link with the dll. There may be a DLL'less mingw32 port, but I am not sure. -----Original Message----- From: Lorenzo Bettini [ mailto:bettini@gdn.dsi.unifi.it ] Sent: Tuesday, June 22, 1999 12:31 AM To: cygwin-developers@sourceware.cygnus.com Subject: DLL Hi I've just installed versione 2 under win98... I'd like to create an exe that doesn't need the dll: actually I'm just using bison and flex and I'm not using any Unix feature... is that possible? thanx in advance Lorenzo -- +-----------------------------------------------------+ | Lorenzo Bettini ICQ# lbetto, 16080134 | | PhD student in Informatica (Computer Science) | | Florence - Italy | | Home Page : http://w3.newnet.it/bettini | | http://infostud.dsi.unifi.it/~bettini | | Mail Home : lorenzo.bettini@penteres.it | | Mail University : bettini@infostud.dsi.unifi.it | | http://www.mokabyte.it Java on line journal | | http://rap.dsi.unifi.it/xklaim XKlaim language | +-----------------------------------------------------+ From cgf@cygnus.com Tue Jun 22 08:36:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Tue, 22 Jun 1999 08:36:00 -0000 Subject: DLL References: <376F1F7F.4F6AAD09@gdn.dsi.unifi.it> <376F1F7F.4F6AAD09@gdn.dsi.unifi.it> Message-ID: <19990622113632.A27704@cygnus.com> This type of question is really not appropriate for cygwin-developers. If you are "not using any Unix feature" then you obviously aren't using the Cygwin DLL and obviously aren't interested in cygwin development. That's fine, but please use the other general mailing list for these kind of questions. -chris On Tue, Jun 22, 1999 at 07:30:39AM +0200, Lorenzo Bettini wrote: > I've just installed versione 2 under win98... I'd like to create an exe >that doesn't need the dll: actually I'm just using bison and flex and >I'm not using any Unix feature... > is that possible? From bettini@gdn.dsi.unifi.it Tue Jun 22 09:05:00 1999 From: bettini@gdn.dsi.unifi.it (Lorenzo Bettini) Date: Tue, 22 Jun 1999 09:05:00 -0000 Subject: DLL References: <19990622113632.A27704@cygnus.com> Message-ID: On Tue, 22 Jun 1999, Chris Faylor wrote: > This type of question is really not appropriate for cygwin-developers. > If you are "not using any Unix feature" then you obviously aren't using > the Cygwin DLL and obviously aren't interested in cygwin development. > > That's fine, but please use the other general mailing list for these > kind of questions. > opsss Do you mean that this list is for those who are developing cygnus tools? I thought it was for developers that are using those tools. sorry for misunderstanding. my apologies Lorenzo -- +-----------------------------------------------------+ | Lorenzo Bettini ICQ# lbetto, 16080134 | | PhD student in Informatica (Computer Science) | | Florence - Italy | | Home Page : http://w3.newnet.it/bettini | | http://infostud.dsi.unifi.it/~bettini | | Mail Home : lorenzo.bettini@penteres.it | | Mail University : bettini@infostud.dsi.unifi.it | | http://www.mokabyte.it Java on line journal | | http://rap.dsi.unifi.it/xklaim XKlaim language | +-----------------------------------------------------+ From deo@logos-m.ru Tue Jun 22 11:28:00 1999 From: deo@logos-m.ru (Egor Duda) Date: Tue, 22 Jun 1999 11:28:00 -0000 Subject: Massive checkin but still no memory corruption fix Message-ID: <17929.990622@logos-m.ru> Hi! Jun 22 1999 Chris Faylor wrote: CF> I've also added the pseudo-JIT debugging from Egor Dada, although I CF> wouldn't recommend using quite yet. It has a tendency to invoke CF> itself a little aggressively. It obviously needs to be a little more CF> integrated with gdb. Does it mean that my assignment had finally come? I've just thought if i should send another copy. And what do you mean "aggressively"? I am to spend some time at weekend to do some additions and cleanups (like storing program name and signal in core file and more extensive parameters checking in dumper -- it traps itself one time while i'm using it). So it would be nice to hear your opinion on what else should be done. Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 From cgf@cygnus.com Tue Jun 22 12:33:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Tue, 22 Jun 1999 12:33:00 -0000 Subject: Massive checkin but still no memory corruption fix References: <17929.990622@logos-m.ru> <17929.990622@logos-m.ru> Message-ID: <19990622153347.A29503@cygnus.com> On Tue, Jun 22, 1999 at 10:18:50PM +0400, Egor Duda wrote: >Jun 22 1999 Chris Faylor wrote: > > CF> I've also added the pseudo-JIT debugging from Egor Dada, although I > CF> wouldn't recommend using quite yet. It has a tendency to invoke > CF> itself a little aggressively. It obviously needs to be a little more > CF> integrated with gdb. > >Does it mean that my assignment had finally come? I've just thought if >i should send another copy. I haven't heard that it had come but I really needed to use your changes, so I added it. Would it be possible for you to fax me a copy of the form? My fax number is 508 632 6528 (with whatever extra codes you'd need to call the US). Or, if it is convenient, you can send me a scanned copy of the assignment. >And what do you mean "aggressively"? I am to spend some time at >weekend to do some additions and cleanups (like storing program name >and signal in core file and more extensive parameters checking in >dumper -- it traps itself one time while i'm using it). So it would be >nice to hear your opinion on what else should be done. If you are debugging a program which receives a SIGSEGV, it forks a separate debugger where it shouldn't. I had one case where a bug in the DLL caused *a lot* of these to show up on my screen. I had a really hard time trying to get rid of them. I was thinking that one way to get around this behavior would be to have gdb set CYGWIN=noerror_start. That may be all that's required. I also made a few changes to your implementation. I converted the filename to UNIX format in the initialization phase since I was seeing problems where a DLL bug caused pathname conversion at a certain point. Actually it might be safest not to call any cygwin function to convert the path name but just to change all of the backslashes to forward slashes. That should work. I also added some code to call try_to_debug on a SIGABRT or SIGQUIT. Anyway, please take a look at the minor changes that I made to your implementation. They should be in last night's snapshot. -chris From khan@xraylith.wisc.EDU Tue Jun 22 14:56:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Tue, 22 Jun 1999 14:56:00 -0000 Subject: handling SIGFPE and resetting the FPU Message-ID: <199906222155.QAA22633@mercury.xraylith.wisc.edu> While trying to build libstdc++-v3, I ran into an odd problem with handling FPE in b20.1. If this is fixed in dev snapshots, please ignore this message. The problem is this: let's say you have a handler for FPE and it gets triggered by a an integer divide by zero; handler gets called and everybody's happy. Let's say you get another of these div_by_0 and now the handler never gets called and the process goes to sleep waiting for SIGFPE to be unblocked according to strace. I believe that the solution is to reset the FPU after handling (which includes the rather dangerous act of ignoring FPE) *each* FP exception in exceptions.cc:handle_exceptions(). That's what I do in Mingw runtime which runs the attached test code ok. Where's the patch you say? I have no patch is because I have no clue what it takes to reset the damn thing, but I assume it's a few-liner x86 assembly code for those in the know. Here's a test code (adapted from libstdc++-v3 src/gen-num-limits.cc): To test: $ c++ -g -o fpe-bug fpe-bug.cc $ ./fpe-bug If the bug is there, it'll get stuck in the test after getting through , , ... trap tests. is the one that gets the FPU all messed up, and gets stuck. === fpe-bug.cc: cut from here to end #include #include #include #include #include using namespace std; jmp_buf env; void signal_handler (int sig) { cerr << "In signal handler: " << sig << endl; longjmp(env, sig); } template bool trapping (const Operation& op) { if (setjmp(env) == 0) op(); else { cerr << "trapping: Returning from longjmp. " << endl; return true; } return false; } template struct division_by_zero { void operator() () const { volatile T zero = T(); volatile T one = T(1); volatile T infinity = one / zero; } }; template struct overflow { void operator() () const { T i = T (1); T j = T (); while (i > j) { j = i; i = i * 2 + 1; } } }; template struct underflow {}; template void traps() { cerr << __PRETTY_FUNCTION__ << ": Enter" << endl; #ifndef NO_SIGHANDLER signal (SIGFPE, signal_handler); #endif bool trap_flag = trapping (division_by_zero ()); cerr << "After trapping division_by_zero" << endl; #ifndef NO_SIGHANDLER signal (SIGFPE, signal_handler); #endif trap_flag = trap_flag && trapping (overflow ()); cerr << "After trapping overflow" << endl; cerr << __PRETTY_FUNCTION__ << ": Leave" << endl; } // type traits template struct type_trait { type_trait() { traps(); } }; int main () { cerr << "Testing ..." << endl; type_trait (); cerr << "Testing ..." << endl; type_trait (); #ifndef HIDE_BUG cerr << "Testing ..." << endl; type_trait (); cerr << "Testing ..." << endl; type_trait (); #endif /* HIDE_BUG */ return 0; } From khan@xraylith.wisc.EDU Wed Jun 23 09:57:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Wed, 23 Jun 1999 09:57:00 -0000 Subject: (patch) add missing math exports Message-ID: <199906231549.KAA00789@mercury.xraylith.wisc.edu> Adds a few missing things from cygwin.din. Gamma et al used to be there in back during b17.1-19 days, but went awol in b20. Wed Jun 23 10:39:07 1999 Mumit Khan * cygwin.din (gamma, gammaf, lgamma, lgammaf): Export. (j0,j0f,j1,j1f,jn,jnf): Export underscore versions as well. Index: cygwin.din =================================================================== RCS file: /homes/khan/src/CVSROOT/cygwin-dev/winsup/cygwin.din,v retrieving revision 1.1.1.1 diff -u -3 -p -u -p -r1.1.1.1 cygwin.din --- cygwin.din 1999/05/03 15:22:19 1.1.1.1 +++ cygwin.din 1999/06/23 15:38:49 @@ -265,6 +265,10 @@ ftruncate _ftruncate = ftruncate fwrite _fwrite = fwrite +gamma +_gamma = gamma +gammaf +_gammaf = gammaf gcvt _gcvt = gcvt gcvtf @@ -370,11 +374,17 @@ _isupper = isupper isxdigit _isxdigit = isxdigit j0 +_j0 = j0 j0f +_j0f = j0f j1 +_j1 = j1 j1f +_j1f = j1f jn +_jn = jn jnf +_jnf = jnf kill _kill = kill labs @@ -385,6 +395,10 @@ ldexpf _ldexpf = ldexpf ldiv _ldiv = ldiv +lgamma +_lgamma = lgamma +lgammaf +_lgammaf = lgammaf link _link = link localeconv Regards, Mumit From fortinj@ibm.net Sat Jun 26 19:59:00 1999 From: fortinj@ibm.net (John Fortin) Date: Sat, 26 Jun 1999 19:59:00 -0000 Subject: efence problems - answered Message-ID: <377594D4.3E910C8A@ibm.net> Hi Chris, I was messing around with efence because of the discussions in the developers list. Here is what I have discovered... All the following occurs during cygwin1.dll startup. The program was a simple hello world program with a malloc(1000) thrown in. 1) during DLL initialization, a call to malloc is made. Since I am linked with efence, the efence malloc gets called. In efence.c:initialize() a call to getenv() is made to find is there is an environment variable EF_ALIGNMENT. Program received signal SIGSEGV, Segmentation fault. 0x61006f92 in _findenv (name=0x401663 "EF_ALIGNMENT", offset=0x258fd70) at /d/src/winsup/environ.cc:147 147 return NULL; (gdb) where #0 0x61006f92 in _findenv (name=0x401663 "EF_ALIGNMENT", offset=0x258fd70) at /d/src/winsup/environ.cc:147 #1 0x61006fb7 in getenv (name=0x401663 "EF_ALIGNMENT") at /d/src/winsup/environ.cc:161 #2 0x4016e0 in initialize () at efence.c:326 #3 0x402435 in malloc (size=16) at efence.c:892 #4 0x6101da9e in malloc (size=16) at /d/src/winsup/malloc.cc:42 #5 0x6101ddff in malloc_init () at /d/src/winsup/malloc.cc:156 #6 0x6101bf9a in heap_init () at /d/src/winsup/heap.cc:46 #7 0x610041d3 in dll_crt0_1 () at /d/src/winsup/dcrt0.cc:616 #8 0x610045d7 in dll_crt0 (uptr=0x4040e0) at /d/src/winsup/dcrt0.cc:770 #9 0x402b6a in cygwin_crt0 (f=0x40152c
) at /d/src/winsup/libccrt0.cc:82 (gdb) However, It looks like the 'environ' variable which holds the environment is not inited yet. Hence, a seg-fault. (The following is in environ.cc) (gdb) n 137 len++; (gdb) n 140 for (p = environ; *p; ++p) (gdb) p environ $1 = (char **) 0x0 (gdb) p *p $2 = 0x258fe0c "\034_X\002j+@" (gdb) whatis p type = char ** (gdb) whatis *p type = char * (gdb) p (short)(char *)p $3 = 16608 (gdb) whatis p type = char ** (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x61006f92 in _findenv (name=0x401663 "EF_ALIGNMENT", offset=0x258fd70) at /d/src/winsup/environ.cc:147 147 return NULL; I modified efence not to use the environment variables, and this behavior stopped. Then the following occurred... 2) in efence.c:initialize() it calls page.c:Page_Create(). Page_Create() calls mmap(). (mmap.cc:175) mmapped_areas = new map; if (mmapped_areas == 0) { set_errno (ENOMEM); syscall_printf ("-1 = mmap(): ENOMEM"); return (caddr_t) -1; } mmap() uses the C++ new method for allocating memory. However, when we look at the stack trace we see that 'new' eventually uses malloc(), which call efence.c:malloc which calls efence.c:initialize() which calls page.c:Page_Create() which calls mmap()......... This continues until a seg-fault occurs. I don't know a solution for this one. Thanks, John Fortin (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /e/efence/hello.exe GDI32.DLL (symbols previously loaded) USER32.DLL (symbols previously loaded) KERNEL32.DLL (symbols previously loaded) ADVAPI32.DLL (symbols previously loaded) CYGWIN1.DLL (symbols previously loaded) Program received signal SIGSEGV, Segmentation fault. write (fd=4198520, buf=0x59205c, cnt=0) at /d/src/newlib/libc/syscalls/syswrite.c:11 11 { (gdb) where #0 write (fd=4198520, buf=0x59205c, cnt=0) at /d/src/newlib/libc/syscalls/syswrite.c:11 #1 0x402465 in EF_Print ( pattern=0x401078 "\n Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Per ens \n") at print.c:182 #2 0x40113d in initialize () at efence.c:297 #3 0x401ead in malloc (size=12) at efence.c:892 #4 0x6101da9e in malloc (size=12) at /d/src/winsup/malloc.cc:42 #5 0x6105ffbb in new_eh_context () #6 0x6106003d in eh_context_static () #7 0x6105fffa in __get_eh_context () #8 0x61060eb9 in __builtin_new (sz=12) #9 0x6101e324 in mmap (addr=0x0, len=1048576, prot=3, flags=34, fd=-1, off=0) at /d/src/winsup/mmap.cc:175 #10 0x401f8d in Page_Create (size=1048576) at page.c:71 #11 0x40139c in initialize () at efence.c:395 #12 0x401ead in malloc (size=12) at efence.c:892 #13 0x6101da9e in malloc (size=12) at /d/src/winsup/malloc.cc:42 #14 0x6105ffbb in new_eh_context () #15 0x6106003d in eh_context_static () #16 0x6105fffa in __get_eh_context () #17 0x61060eb9 in __builtin_new (sz=12) #18 0x6101e324 in mmap (addr=0x0, len=1048576, prot=3, flags=34, fd=-1, off=0) at /d/src/winsup/mmap.cc:175 #19 0x401f8d in Page_Create (size=1048576) at page.c:71 #20 0x40139c in initialize () at efence.c:395 #21 0x401ead in malloc (size=12) at efence.c:892 #22 0x6101da9e in malloc (size=12) at /d/src/winsup/malloc.cc:42 #23 0x6105ffbb in new_eh_context () #24 0x6106003d in eh_context_static () #25 0x6105fffa in __get_eh_context () #26 0x61060eb9 in __builtin_new (sz=12) #27 0x6101e324 in mmap (addr=0x0, len=1048576, prot=3, flags=34, fd=-1, off=0) at /d/src/winsup/mmap.cc:175 #28 0x401f8d in Page_Create (size=1048576) at page.c:71 #29 0x40139c in initialize () at efence.c:395 #30 0x401ead in malloc (size=12) at efence.c:892 #31 0x6101da9e in malloc (size=12) at /d/src/winsup/malloc.cc:42 #32 0x6105ffbb in new_eh_context () #33 0x6106003d in eh_context_static () #34 0x6105fffa in __get_eh_context () #35 0x61060eb9 in __builtin_new (sz=12) #36 0x6101e324 in mmap (addr=0x0, len=1048576, prot=3, flags=34, fd=-1, off=0) at /d/src/winsup/mmap.cc:175 #37 0x401f8d in Page_Create (size=1048576) at page.c:71 #38 0x40139c in initialize () at efence.c:395 From cgf@cygnus.com Sat Jun 26 20:04:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Sat, 26 Jun 1999 20:04:00 -0000 Subject: efence problems - answered References: <377594D4.3E910C8A@ibm.net> <377594D4.3E910C8A@ibm.net> Message-ID: <19990626230519.A13628@cygnus.com> Linking in an "alien" malloc into cygwin is going to be very tough. I've got cygwin linked with a debugging malloc now and seem to have located my problems. Now I'm suffering from gcc problems. I can't even build cygwin right now. Sigh. -chris On Sat, Jun 26, 1999 at 11:04:52PM -0400, John Fortin wrote: > I was messing around with efence because of the discussions in the >developers list. Here is what I have discovered... All the following >occurs during cygwin1.dll startup. The program was a simple hello world >program with a malloc(1000) thrown in. > >1) during DLL initialization, a call to malloc is made. Since I am >linked with efence, the efence malloc gets called. In >efence.c:initialize() a call to getenv() is made to find is there is an >environment variable EF_ALIGNMENT. > >Program received signal SIGSEGV, Segmentation fault. >0x61006f92 in _findenv (name=0x401663 "EF_ALIGNMENT", offset=0x258fd70) > at /d/src/winsup/environ.cc:147 >147 return NULL; >(gdb) where >#0 0x61006f92 in _findenv (name=0x401663 "EF_ALIGNMENT", >offset=0x258fd70) > at /d/src/winsup/environ.cc:147 >#1 0x61006fb7 in getenv (name=0x401663 "EF_ALIGNMENT") > at /d/src/winsup/environ.cc:161 >#2 0x4016e0 in initialize () at efence.c:326 >#3 0x402435 in malloc (size=16) at efence.c:892 >#4 0x6101da9e in malloc (size=16) at /d/src/winsup/malloc.cc:42 >#5 0x6101ddff in malloc_init () at /d/src/winsup/malloc.cc:156 >#6 0x6101bf9a in heap_init () at /d/src/winsup/heap.cc:46 >#7 0x610041d3 in dll_crt0_1 () at /d/src/winsup/dcrt0.cc:616 >#8 0x610045d7 in dll_crt0 (uptr=0x4040e0) at /d/src/winsup/dcrt0.cc:770 >#9 0x402b6a in cygwin_crt0 (f=0x40152c
) at >/d/src/winsup/libccrt0.cc:82 >(gdb) > >However, It looks like the 'environ' variable which holds the >environment is not inited yet. Hence, a seg-fault. >(The following is in environ.cc) > >(gdb) n >137 len++; >(gdb) n >140 for (p = environ; *p; ++p) >(gdb) p environ >$1 = (char **) 0x0 >(gdb) p *p >$2 = 0x258fe0c "\034_X\002j+@" >(gdb) whatis p >type = char ** >(gdb) whatis *p >type = char * >(gdb) p (short)(char *)p >$3 = 16608 >(gdb) whatis p >type = char ** >(gdb) n > >Program received signal SIGSEGV, Segmentation fault. >0x61006f92 in _findenv (name=0x401663 "EF_ALIGNMENT", offset=0x258fd70) > at /d/src/winsup/environ.cc:147 >147 return NULL; > >I modified efence not to use the environment variables, and this >behavior stopped. Then the following occurred... > > >2) in efence.c:initialize() it calls page.c:Page_Create(). >Page_Create() calls mmap(). > >(mmap.cc:175) mmapped_areas = new map; > if (mmapped_areas == 0) > { > set_errno (ENOMEM); > syscall_printf ("-1 = mmap(): ENOMEM"); > return (caddr_t) -1; > } > > >mmap() uses the C++ new method for allocating memory. However, when we >look at the stack trace we see that >'new' eventually uses malloc(), which call efence.c:malloc which calls >efence.c:initialize() which calls page.c:Page_Create() which calls >mmap()......... This continues until a seg-fault occurs. I don't know >a solution for this one. > >Thanks, >John Fortin > >(gdb) run >The program being debugged has been started already. >Start it from the beginning? (y or n) y >Starting program: /e/efence/hello.exe >GDI32.DLL (symbols previously loaded) >USER32.DLL (symbols previously loaded) >KERNEL32.DLL (symbols previously loaded) >ADVAPI32.DLL (symbols previously loaded) >CYGWIN1.DLL (symbols previously loaded) > >Program received signal SIGSEGV, Segmentation fault. >write (fd=4198520, buf=0x59205c, cnt=0) > at /d/src/newlib/libc/syscalls/syswrite.c:11 >11 { >(gdb) where >#0 write (fd=4198520, buf=0x59205c, cnt=0) > at /d/src/newlib/libc/syscalls/syswrite.c:11 >#1 0x402465 in EF_Print ( > pattern=0x401078 "\n Electric Fence 2.2.0 Copyright (C) 1987-1999 >Bruce Per >ens \n") at print.c:182 >#2 0x40113d in initialize () at efence.c:297 >#3 0x401ead in malloc (size=12) at efence.c:892 >#4 0x6101da9e in malloc (size=12) at /d/src/winsup/malloc.cc:42 >#5 0x6105ffbb in new_eh_context () >#6 0x6106003d in eh_context_static () >#7 0x6105fffa in __get_eh_context () >#8 0x61060eb9 in __builtin_new (sz=12) >#9 0x6101e324 in mmap (addr=0x0, len=1048576, prot=3, flags=34, fd=-1, >off=0) > at /d/src/winsup/mmap.cc:175 >#10 0x401f8d in Page_Create (size=1048576) at page.c:71 >#11 0x40139c in initialize () at efence.c:395 >#12 0x401ead in malloc (size=12) at efence.c:892 >#13 0x6101da9e in malloc (size=12) at /d/src/winsup/malloc.cc:42 >#14 0x6105ffbb in new_eh_context () >#15 0x6106003d in eh_context_static () >#16 0x6105fffa in __get_eh_context () >#17 0x61060eb9 in __builtin_new (sz=12) >#18 0x6101e324 in mmap (addr=0x0, len=1048576, prot=3, flags=34, fd=-1, >off=0) > at /d/src/winsup/mmap.cc:175 >#19 0x401f8d in Page_Create (size=1048576) at page.c:71 >#20 0x40139c in initialize () at efence.c:395 >#21 0x401ead in malloc (size=12) at efence.c:892 >#22 0x6101da9e in malloc (size=12) at /d/src/winsup/malloc.cc:42 >#23 0x6105ffbb in new_eh_context () >#24 0x6106003d in eh_context_static () >#25 0x6105fffa in __get_eh_context () >#26 0x61060eb9 in __builtin_new (sz=12) >#27 0x6101e324 in mmap (addr=0x0, len=1048576, prot=3, flags=34, fd=-1, >off=0) > at /d/src/winsup/mmap.cc:175 >#28 0x401f8d in Page_Create (size=1048576) at page.c:71 >#29 0x40139c in initialize () at efence.c:395 >#30 0x401ead in malloc (size=12) at efence.c:892 >#31 0x6101da9e in malloc (size=12) at /d/src/winsup/malloc.cc:42 >#32 0x6105ffbb in new_eh_context () >#33 0x6106003d in eh_context_static () >#34 0x6105fffa in __get_eh_context () >#35 0x61060eb9 in __builtin_new (sz=12) >#36 0x6101e324 in mmap (addr=0x0, len=1048576, prot=3, flags=34, fd=-1, >off=0) > at /d/src/winsup/mmap.cc:175 >#37 0x401f8d in Page_Create (size=1048576) at page.c:71 From cgf@cygnus.com Sat Jun 26 20:31:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Sat, 26 Jun 1999 20:31:00 -0000 Subject: Repost: different files have the same i-node number. References: Message-ID: <19990626233223.C13764@cygnus.com> I've noticed that the problem below seems to happen sporadically on Windows NT on a FAT file system. So, I have added a check for the file system rather than the OS. You will be able to see this in a snapshot as soon as we get gcc working here again so that it can build cygwin. Currently it's broken, unfortunately. -chris On Sun, Jun 13, 1999 at 08:37:21AM +0900, Kazuhiro Fujieda wrote: >In recent snapshots, different files sometime have the same i-node >number on Win9x. This is caused by the following code in fhandler.cc. > >882: buf->st_ino = local.nFileIndexHigh | local.nFileIndexLow; > >This value isn't quiet unique on Win9x, so i-node should be based on >a hash number like the past snapshots on Win9x. From cgf@cygnus.com Sun Jun 27 14:19:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Sun, 27 Jun 1999 14:19:00 -0000 Subject: Hey! A snapshot! Message-ID: <19990627172006.A8388@cygnus.com> It looks like our gcc problems have been worked around so there is a new 26-June-1999 snapshot available for the morbidly curious... -- cgf@cygnus.com http://www.cygnus.com/ From khan@xraylith.wisc.EDU Sun Jun 27 14:36:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Sun, 27 Jun 1999 14:36:00 -0000 Subject: Hey! A snapshot! References: <19990627172006.A8388@cygnus.com> Message-ID: <199906272136.QAA08646@mercury.xraylith.wisc.edu> Chris Faylor writes: > It looks like our gcc problems have been worked around so there is a new > 26-June-1999 snapshot available for the morbidly curious... > Could you please explain a bit what these problems are/were and what workarounds are needed? Regards, Mumit From cgf@cygnus.com Sun Jun 27 15:42:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Sun, 27 Jun 1999 15:42:00 -0000 Subject: Hey! A snapshot! References: <19990627172006.A8388@cygnus.com> <199906272136.QAA08646@mercury.xraylith.wisc.edu> <199906272136.QAA08646@mercury.xraylith.wisc.edu> Message-ID: <19990627184406.A8416@cygnus.com> On Sun, Jun 27, 1999 at 04:36:15PM -0500, Mumit Khan wrote: >Chris Faylor writes: >> It looks like our gcc problems have been worked around so there is a new >> 26-June-1999 snapshot available for the morbidly curious... > >Could you please explain a bit what these problems are/were and what >workarounds are needed? I would if I could. One problem was an internal compiler error when compiling syscalls.cc. Another was a "cc1 looping" problem when compiling environ.cc and others. I believe that both were due to internal Cygnus development that hadn't hit EGCS yet, but I could be mistaken. We received patches from g++ and gcc engineers that worked around the problem. They're awaiting review before being put into the main gcc sources. cgf From khan@xraylith.wisc.EDU Sun Jun 27 16:26:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Sun, 27 Jun 1999 16:26:00 -0000 Subject: Hey! A snapshot! References: <19990627184406.A8416@cygnus.com> Message-ID: <199906272326.SAA19813@mercury.xraylith.wisc.edu> Chris Faylor writes: > On Sun, Jun 27, 1999 at 04:36:15PM -0500, Mumit Khan wrote: > >Could you please explain a bit what these problems are/were and what > >workarounds are needed? > > I would if I could. One problem was an internal compiler error when > compiling syscalls.cc. Another was a "cc1 looping" problem when > compiling environ.cc and others. > > I believe that both were due to internal Cygnus development that hadn't > hit EGCS yet, but I could be mistaken. I haven't seen either, so it must be due to what you suspect. Glad things are working now. fyi, I can build 1999-06-26 with gcc-2.95-1999-06-26. Regards, Mumit From khan@xraylith.wisc.EDU Sun Jun 27 19:58:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Sun, 27 Jun 1999 19:58:00 -0000 Subject: running two independent Cygwin DLLs? Message-ID: <199906280258.VAA23658@mercury.xraylith.wisc.edu> I need to get a setup where I'm running two perhaps incompatible Cygwin DLLs, and wondering if that makes any sense at all. This is what I've done: - have stock Cygwin dll etc running everything including remote access (that's why I can't just replace the current one etc) - modify the 2nd one (this is a new snapshot) to * have a different name, say cygwin1-test.dll, and regenerate the import library accordingly, so that the newly linked apps will refer to this instead. * change the shared address and name so that the new DLL won't see the values for the stock one. Would this work, or am I fooling myself? I can see some potential pitfalls such as mount table issues, but is there something fatal waiting to happen? Regards, Mumit From dj@delorie.com Sun Jun 27 20:06:00 1999 From: dj@delorie.com (DJ Delorie) Date: Sun, 27 Jun 1999 20:06:00 -0000 Subject: running two independent Cygwin DLLs? References: <199906280258.VAA23658@mercury.xraylith.wisc.edu> <199906280258.VAA23658@mercury.xraylith.wisc.edu> Message-ID: <199906280305.XAA00938@envy.delorie.com> > * have a different name, say cygwin1-test.dll, and regenerate the > import library accordingly, so that the newly linked apps will > refer to this instead. Hmmm... Makefile and cygwin.din should do it. Also change cygwin.din's BASE to avoid relocation overhead. > * change the shared address and name so that the new DLL won't > see the values for the stock one. You'll also need to change some of the version parameters in winsup/include/cygwin/version.h to use a different shared memory region and/or other shared resources. Note that this means that a parent using one dll will treat a child using the other dll as a non-cygwin program, and visa versa. From cgf@cygnus.com Sun Jun 27 20:07:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Sun, 27 Jun 1999 20:07:00 -0000 Subject: running two independent Cygwin DLLs? References: <199906280258.VAA23658@mercury.xraylith.wisc.edu> <199906280258.VAA23658@mercury.xraylith.wisc.edu> Message-ID: <19990627230839.A8904@cygnus.com> On Sun, Jun 27, 1999 at 09:58:15PM -0500, Mumit Khan wrote: >I need to get a setup where I'm running two perhaps incompatible Cygwin >DLLs, and wondering if that makes any sense at all. This is what I've >done: > - have stock Cygwin dll etc running everything including remote access > (that's why I can't just replace the current one etc) > - modify the 2nd one (this is a new snapshot) to > * have a different name, say cygwin1-test.dll, and regenerate the > import library accordingly, so that the newly linked apps will > refer to this instead. > * change the shared address and name so that the new DLL won't > see the values for the stock one. > >Would this work, or am I fooling myself? I can see some potential >pitfalls such as mount table issues, but is there something fatal >waiting to happen? It should work. The only mount table issues that I can think of is if you mount something using one DLL and expect it to show up instantly in applications using the other DLL. Note that you won't be able to pass signals between the two DLLs and so a CTRL-C sent via a bash using one DLL will always terminate a process running another DLL. Actually, there may be one problem in an upcoming snapshot. I've modified the DLL to refuse to run if it detects that it is being used via exec or fork from a different DLL. This probably still won't cause a problem in your above case as long as you are careful to always use the right DLL/binary combination. My only request is: Please! Don't even think of advising anyone to do this at home. It has great potential for problems and I really don't want to see people attempting this on the cygwin mailing list. My standard response to cygwin users has always been to keep only one version of the DLL on the system. That is always the safest way to do things. But, of course you already know that... :-) Good Luck, -chris From cgf@cygnus.com Sun Jun 27 20:09:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Sun, 27 Jun 1999 20:09:00 -0000 Subject: running two independent Cygwin DLLs? References: <199906280258.VAA23658@mercury.xraylith.wisc.edu> <199906280305.XAA00938@envy.delorie.com> <199906280305.XAA00938@envy.delorie.com> Message-ID: <19990627231051.B8904@cygnus.com> On Sun, Jun 27, 1999 at 11:05:57PM -0400, DJ Delorie wrote: > >> * have a different name, say cygwin1-test.dll, and regenerate the >> import library accordingly, so that the newly linked apps will >> refer to this instead. > >Hmmm... Makefile and cygwin.din should do it. Also change >cygwin.din's BASE to avoid relocation overhead. This shouldn't be an issue should it? There's only going to be one DLL linked into the process address space at any time. >> * change the shared address and name so that the new DLL won't >> see the values for the stock one. > >You'll also need to change some of the version parameters in >winsup/include/cygwin/version.h to use a different shared memory >region and/or other shared resources. Note that this means that a >parent using one dll will treat a child using the other dll as a >non-cygwin program, and visa versa. Actually, all you have to do is "configure --enable-debugging". That will cause the shared memory regions to be named based on the date/time. cgf From dj@delorie.com Sun Jun 27 20:12:00 1999 From: dj@delorie.com (DJ Delorie) Date: Sun, 27 Jun 1999 20:12:00 -0000 Subject: running two independent Cygwin DLLs? References: <199906280258.VAA23658@mercury.xraylith.wisc.edu> <199906280305.XAA00938@envy.delorie.com> <19990627231051.B8904@cygnus.com> <19990627231051.B8904@cygnus.com> Message-ID: <199906280312.XAA00996@envy.delorie.com> > This shouldn't be an issue should it? There's only going to be one > DLL linked into the process address space at any time. That depends on how Windows maps DLLs. I'm fearful that two applications that both import from "cygwin1.dll" will share a dll, even if the search path would result in different dlls being found. If you're debugging a dll yet relying on a stock dll at the same time, it's prudent to give them separate names. > Actually, all you have to do is "configure --enable-debugging". That > will cause the shared memory regions to be named based on the date/time. What about the mount tables, though? Depending on *what* you're experimenting with, you may still need to isolate other parts of the dll's shared resources. From cgf@cygnus.com Sun Jun 27 20:14:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Sun, 27 Jun 1999 20:14:00 -0000 Subject: running two independent Cygwin DLLs? References: <199906280258.VAA23658@mercury.xraylith.wisc.edu> <199906280305.XAA00938@envy.delorie.com> <19990627231051.B8904@cygnus.com> <199906280312.XAA00996@envy.delorie.com> <199906280312.XAA00996@envy.delorie.com> Message-ID: <19990627231554.A8977@cygnus.com> On Sun, Jun 27, 1999 at 11:12:03PM -0400, DJ Delorie wrote: >> Actually, all you have to do is "configure --enable-debugging". That >> will cause the shared memory regions to be named based on the date/time. > >What about the mount tables, though? Depending on *what* you're >experimenting with, you may still need to isolate other parts of the >dll's shared resources. The mount info is stored in the shared memory region. Using --enable-debugging should isolate everything since it affects the base name that is used to generate shared resources. cgf From dj@delorie.com Sun Jun 27 20:16:00 1999 From: dj@delorie.com (DJ Delorie) Date: Sun, 27 Jun 1999 20:16:00 -0000 Subject: running two independent Cygwin DLLs? References: <199906280258.VAA23658@mercury.xraylith.wisc.edu> <199906280305.XAA00938@envy.delorie.com> <19990627231051.B8904@cygnus.com> <199906280312.XAA00996@envy.delorie.com> <19990627231554.A8977@cygnus.com> <19990627231554.A8977@cygnus.com> Message-ID: <199906280316.XAA01031@envy.delorie.com> > The mount info is stored in the shared memory region. Using > --enable-debugging should isolate everything since it affects the base > name that is used to generate shared resources. I was thinking of the permanent table, in the registry. If you want to play with the mount API you'd want to use a separate registry key as well. From khan@xraylith.wisc.EDU Sun Jun 27 20:38:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Sun, 27 Jun 1999 20:38:00 -0000 Subject: running two independent Cygwin DLLs? References: <19990627230839.A8904@cygnus.com> Message-ID: <199906280336.WAA24373@mercury.xraylith.wisc.edu> Chris and DJ, Thanks for the useful discussion. I'm running it right now, but I'm running into some debugging problems unfortunately. GDB seems to be getting SIGTRAP in the child (which is using this new modified DLL), but only at times. However, the linked program run just fine. It's probably best to just find another machine and use that instead. For once I regret getting rid windows from my laptop. How do you guys do it? Keep in mind that I never work on a windows box, so go slow please. > > My only request is: Please! Don't even think of advising anyone > to do this at home. It has great potential for problems and I really > don't want to see people attempting this on the cygwin mailing list. > My standard response to cygwin users has always been to keep only one > version of the DLL on the system. That is always the safest way to > do things. That's the reason I posted to the cygwin-dev list hoping that most people here already know the dangers of playing with fire ;-) Regards, Mumit From cgf@cygnus.com Sun Jun 27 20:44:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Sun, 27 Jun 1999 20:44:00 -0000 Subject: running two independent Cygwin DLLs? References: <19990627230839.A8904@cygnus.com> <199906280336.WAA24373@mercury.xraylith.wisc.edu> <199906280336.WAA24373@mercury.xraylith.wisc.edu> Message-ID: <19990627234525.A9093@cygnus.com> On Sun, Jun 27, 1999 at 10:36:31PM -0500, Mumit Khan wrote: >How do you guys do it? Keep in mind that I never work on a windows box, >so go slow please. I have a gdb and a cygwin DLL in a subdirectory not in my path. Then, when I need to debug another DLL, I cd to that directory type 'gdb whatever' and 'cd /' Then when the program runs it picks up the DLL from the path rather than from the subdirectory. Sometimes when that doesn't work I try to attach to the process directly. You can use symbol-file to load a specific DLL's symbols. If there isn't enough time to catch the process in the act, I sometimes add sleeps to various stages of the DLL startup. Also the recent patches to gdb from Egor Dada are nice in that they will fire up a gdb when a process receives a core-dumping signal. >> My only request is: Please! Don't even think of advising anyone >> to do this at home. It has great potential for problems and I really >> don't want to see people attempting this on the cygwin mailing list. >> My standard response to cygwin users has always been to keep only one >> version of the DLL on the system. That is always the safest way to >> do things. > >That's the reason I posted to the cygwin-dev list hoping that most people >here already know the dangers of playing with fire ;-) Yup. I know you know that and I hope that the cygwin-dev folks know it, too but one thing I've learned is that you can't repeat things too often. You really can't. Repeat things, too often. Haw, haw, cgf From dj@delorie.com Sun Jun 27 20:47:00 1999 From: dj@delorie.com (DJ Delorie) Date: Sun, 27 Jun 1999 20:47:00 -0000 Subject: running two independent Cygwin DLLs? References: <199906280336.WAA24373@mercury.xraylith.wisc.edu> <199906280336.WAA24373@mercury.xraylith.wisc.edu> Message-ID: <199906280347.XAA01243@envy.delorie.com> > How do you guys do it? printf and strace are popular ;-) Seriously, I have a batch file that copies a given cygwin dll to all the places it resides on my hard drive, and I have a cache of known good dlls to restore from. When I'm debugging dll problems, the first thing to do is get out of bash and make sure that the *only* cygwin program you're running is the one you're debugging (and/or gdb). Or, I just make sure the debug dll is in the current directory with my test program. From corinna@vinschen.de Wed Jun 30 18:07:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Wed, 30 Jun 1999 18:07:00 -0000 Subject: Change in errno.cc Message-ID: <377AB36C.4A500615@vinschen.de> Hi, If one process has opened a file exclusively or has locked a part of the file, then other processes, which try to open this file, will get either the error code ERROR_SHARING_VIOLATION or the error code ERROR_LOCK_VIOLATION. Both error codes are mapped to EACCES in errno.cc. This doesn't reflect the real situation. So I want to suggest the following change to errno.cc: Change the mapping of the above error codes to ETXTBSY. The patch is attached. Regards, Corinna ChangeLog: ========== Thu Jul 1 2:14:00 Corinna Vinschen * errno.cc: Changed the error mapping of ERROR_SHARING_VIOLATION and ERROR_LOCK_VIOLATION from EACCES to ETXTBSY. Index: errno.cc =================================================================== RCS file: /src/cvsroot/winsup-990627/errno.cc,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 errno.cc --- errno.cc 1999/06/28 09:00:06 1.1.1.1 +++ errno.cc 1999/06/30 23:59:37 @@ -42,8 +42,8 @@ errmap[] = X (NO_MORE_FILES, ENMFILE), X (WRITE_PROTECT, EROFS), X (BAD_UNIT, ENODEV), - X (SHARING_VIOLATION, EACCES), - X (LOCK_VIOLATION, EACCES), + X (SHARING_VIOLATION, ETXTBSY), + X (LOCK_VIOLATION, ETXTBSY), X (SHARING_BUFFER_EXCEEDED, ENOLCK), X (HANDLE_EOF, ENODATA), X (HANDLE_DISK_FULL, ENOSPC), From corinna@vinschen.de Wed Jun 30 18:25:00 1999 From: corinna@vinschen.de (Corinna Vinschen) Date: Wed, 30 Jun 1999 18:25:00 -0000 Subject: strftime and timezone Message-ID: <377AC37D.63B4B4A3@vinschen.de> This question is of interest, since timezone is handled correctly in winsup: Shouldn't %Z now be implemented in strftime? Corinna