Fwd: Stupid Vista-64 tricks

[Georg Nikodym]

Resending from an address that's actually subscribed to the list.

Begin forwarded message:

> From: Georg Nikodym <georgn@...>
> Date: August 24, 2007 14:14:17 EDT (CA)
> To: MinGW Users List <mingw-users@...>
> Cc: cygwin-developers@...
> Subject: Stupid Vista-64 tricks
>
> This is not strictly speaking a cygwin problem.  More a question of  
> what an alien app needs to do to be useful inside a cygwin  
> environment.  So apologies in advance for the intrusion.
>
> Consider the following program:
>
> #include <stdio.h>
> #include <string.h>
> #include <errno.h>
> #include <fcntl.h>
> #include <sys/types.h>
> #include <sys/stat.h>
>
> int
> main(int argc, char **argv)
> {
>         FILE *fp;
>         int fd;
>         mode_t mode;
>
>         chmod("foo", 0666);
>         unlink("foo");
>         chmod("bar", 0666);
>         unlink("bar");
>         chmod("baz", 0666);
>         unlink("baz");
>
>         mode = umask(002);
>         mode = umask(002);
>
>         printf("mode = %o\n", mode);
>
>         fp = fopen("foo", "w");
>         if (fp == NULL) {
>                 fprintf(stderr, "%s: foo: %s (%d)\n", argv[0],
>                         strerror(errno), errno);
>                 exit(1);
>         }
>
>         fclose(fp);
>         chmod("foo", 0777);
>
>         fd = open("bar", O_CREAT|O_WRONLY);
>         if (fd < 0) {
>                 fprintf(stderr, "%s: bar: %s (%d)\n", argv[0],
>                         strerror(errno), errno);
>                 exit(2);
>         }
>
>         close(fd);
>         chmod("bar", 0777);
>
>         fd = open("baz", O_CREAT|O_RDWR, 0644);
>         if (fd < 0) {
>                 fprintf(stderr, "%s: baz: %s (%d)\n", argv[0],
>                         strerror(errno), errno);
>                 exit(2);
>         }
>
>         close(fd);
>         chmod("baz", 0777);
>
>         return 0;
> }
>
> Compiled with mingw's gcc (3.4.5) and run inside an MSYS bash, it  
> operates almost as expected (the umask() and chmod() calls don't  
> quite act the way a UNIX hand like myself would expect).
>
> However, run under a cygwin shell, I see:
>
> georgn@up /tmp
> $ ./temp; ls -l foo bar baz
> mode = 0
> ----------+ 1 georgn None 0 Aug 24 13:50 bar
> ----------+ 1 georgn None 0 Aug 24 13:50 baz
> ----------+ 1 georgn None 0 Aug 24 13:50 foo
>
> georgn@up /tmp
> $
>
> (The annoying problem being, you build an app using the mingw/gcc  
> suite and a customer uses it in a cygwin shell and has things like  
> vi complain about files being read-only.  Just a general, crappy  
> user experience.)
>
> So my questions/options are:
>
> 1) Wrap my fopen/open calls with some win32 work-around that cygwin  
> likes better.  Any thoughts on what that might look like?
> 2) Learn enough about the incompatibility to offer up a patch.  Any  
> thoughts on where to start an investigation?
>
> -g
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Greg Chicares]

On 2007-08-24 23:43Z, Georg Nikodym wrote:
[...]
>> (The annoying problem being, you build an app using the mingw/gcc
>> suite and a customer uses it in a cygwin shell and has things like vi
>> complain about files being read-only.  Just a general, crappy user
>> experience.)

What would you have the MinGW developers do about this? Rewrite
the C runtime library that MinGW uses, to make it Cygwin-aware?

Wouldn't you have the same issue if you built the app with msvc?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[NightStrike]

On 8/24/07, Georg Nikodym <georgn@...> wrote:

> > Compiled with mingw's gcc (3.4.5) and run inside an MSYS bash, it
> > operates almost as expected (the umask() and chmod() calls don't
> > quite act the way a UNIX hand like myself would expect).
> >
> > However, run under a cygwin shell, I see:
> >
> > georgn@up /tmp
> > $ ./temp; ls -l foo bar baz
> > mode = 0
> > ----------+ 1 georgn None 0 Aug 24 13:50 bar
> > ----------+ 1 georgn None 0 Aug 24 13:50 baz
> > ----------+ 1 georgn None 0 Aug 24 13:50 foo
> >
> > georgn@up /tmp
> > $

Can you just compile it for cygwin?  Use i686-pc-cygwin-gcc.exe

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[keithmarshall]

On Saturday 25 August 2007 01:34, Greg Chicares wrote:

> On 2007-08-24 23:43Z, Georg Nikodym wrote:
> [...]
>
> >> (The annoying problem being, you build an app using the mingw/gcc
> >> suite and a customer uses it in a cygwin shell and has things like
> >> vi complain about files being read-only.  Just a general, crappy
> >> user experience.)
>
> What would you have the MinGW developers do about this? Rewrite
> the C runtime library that MinGW uses, to make it Cygwin-aware?

Which kind of flies in the face of MinGW's minimalist objectives; this
certainly isn't going to happen.

> Wouldn't you have the same issue if you built the app with msvc?

I too would expect this to be the case; after all, MinGW and MSVC share
a common underlying API, with virtually no intermediate stuff, of the
kind Cygwin provides.

Regards,
Keith.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[keithmarshall]

On Saturday 25 August 2007 05:33, NightStrike wrote:

> On 8/24/07, Georg Nikodym <georgn@...> wrote:
> > > Compiled with mingw's gcc (3.4.5) and run inside an MSYS bash, it
> > > operates almost as expected (the umask() and chmod() calls don't
> > > quite act the way a UNIX hand like myself would expect).
> > >
> > > However, run under a cygwin shell, I see:
> > >
> > > georgn@up /tmp
> > > $ ./temp; ls -l foo bar baz
> > > mode = 0
> > > ----------+ 1 georgn None 0 Aug 24 13:50 bar
> > > ----------+ 1 georgn None 0 Aug 24 13:50 baz
> > > ----------+ 1 georgn None 0 Aug 24 13:50 foo
> > >
> > > georgn@up /tmp
> > > $
>
> Can you just compile it for cygwin?  Use i686-pc-cygwin-gcc.exe

That seems to miss the point entirely.  If compiled *for* Cygwin, then
the end user needs to *have* Cygwin; if compiled with the MinGW suite,
then it's a native Woe32 application, and the end user just needs a
perfectly ordinary Woe32 system.

Cygwin is *supposed* to be able to run native Woe32 applications; in the
example given, it doesn't do so properly.  That's a Cygwin problem, not
a MinGW issue.

Regards,
Keith.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Georg Nikodym]

On Aug 24, 2007, at 20:34, Greg Chicares wrote:

> On 2007-08-24 23:43Z, Georg Nikodym wrote:
> [...]
>>> (The annoying problem being, you build an app using the mingw/gcc
>>> suite and a customer uses it in a cygwin shell and has things  
>>> like vi
>>> complain about files being read-only.  Just a general, crappy user
>>> experience.)
>
> What would you have the MinGW developers do about this? Rewrite
> the C runtime library that MinGW uses, to make it Cygwin-aware?
>
> Wouldn't you have the same issue if you built the app with msvc?

Thanks for the response.

Well, there's the rub.  Using Visual Studio (2005) I made a slightly  
different program:

  // temp.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "Wtypes.h"
#include "winuser.h"
#include "winbase.h"


int _tmain(int argc, _TCHAR* argv[])
{ HANDLE handle;
/*
        handle = CreateFile(_T("foo"), GENERIC_READ|GENERIC_WRITE, NULL, NULL,
                CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

        CloseHandle(handle);
*/
        FILE *fp;

        fp = fopen("foo", "w");
        if (fp == NULL) {
                fprintf(stderr, "fopen failed\n");
                exit(1);
        }
        fclose(fp);

        return 0;
}

Running the compiled result of this under cygwin yields:

georgn@up /cygdrive/c/Users/georgn/Documents/Visual Studio 2005/
Projects/debug
$ ls -l
total 776
-rwx------+ 1 georgn         None      0 Aug 27 10:52 foo
-rwx------+ 1 Administrators None  40960 Aug 27 10:52 temp.exe
-rwx------+ 1 Administrators None 319952 Aug 27 10:52 temp.ilk
-rwx------+ 1 Administrators None 429056 Aug 27 10:52 temp.pdb


And the result is the same whether I use the CreateFile or fopen  
interfaces.

Is the C runtime that various folks refer to subject to change from  
system to system?  Is there more than one?  Is it a .dll or some  
static wad that gets linked into the .exe?  (Sorry, I'm a long time  
unix hack and this windows stuff is making me mental).

I'm thinking that my next experiment will be to add a sleep, pause,  
whatever and using something like process exploder to learn more.

-g



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Tuomo Latto-3]

Georg Nikodym wrote:
> On Aug 24, 2007, at 20:34, Greg Chicares wrote:
>> Wouldn't you have the same issue if you built the app with msvc?
>
> Thanks for the response.
>
> Well, there's the rub.  Using Visual Studio (2005) I made a slightly
> different program:
[...]

> Running the compiled result of this under cygwin yields:
>
> georgn@up /cygdrive/c/Users/georgn/Documents/Visual Studio
> 2005/Projects/debug
> $ ls -l
> total 776
> -rwx------+ 1 georgn         None      0 Aug 27 10:52 foo
> -rwx------+ 1 Administrators None  40960 Aug 27 10:52 temp.exe
> -rwx------+ 1 Administrators None 319952 Aug 27 10:52 temp.ilk
> -rwx------+ 1 Administrators None 429056 Aug 27 10:52 temp.pdb
>
>
> And the result is the same whether I use the CreateFile or fopen
> interfaces.
>
> Is the C runtime that various folks refer to subject to change from
> system to system?  Is there more than one?  Is it a .dll or some static

Not exactly. Although I'm not actually sure.

However, the runtime is different for each version of MSVC.
VS2005 uses a different runtime than VS2003 and both are different from
the VC6.0 version (msvcrt.dll), which is used by MinGW.

The reason for that is that, at least up until now, only the last one
is actually a(n official?) component of the operating system.
Or at least a common component in all of them (from W95 and NT4 onward).

Apart from being a nice feature (no external dlls, etc), I think that
actually makes it legal to link GPL'd code against it (OS exception).
Which is nice, considering that the most of the toolchain is GPL.


As to your problem, I have no idea why cygwin would see them differently.
Do all executables have the "archive" bit set by default?


--
Tuomo

... Enough research will tend to support your theory


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Georg Nikodym]

On Aug 27, 2007, at 11:40, Tuomo Latto wrote:

> As to your problem, I have no idea why cygwin would see them  
> differently.
> Do all executables have the "archive" bit set by default?

I'm very curious what the significance of the archive bit is expected  
to be.

I've chased this issue down further and the plot thickens a bit.

My test program may or may not work as expected depending the  
directory in which it's run.  Further digging shows that if cygwin  
creates the directory, my test works.  If cmd.exe or some other  
program create the directory, then the test fails.

I've been fooling around with cygwin getfacl/setfacl since that's  
where the difference appears to be...

It's looking definitely like this is not really a mingw problem at all.

Sorry for the interruption and thanks for the pointers,
-g



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Tuomo Latto-3]

Georg Nikodym wrote:
>
> On Aug 27, 2007, at 11:40, Tuomo Latto wrote:
>
>> As to your problem, I have no idea why cygwin would see them differently.
>> Do all executables have the "archive" bit set by default?
>
> I'm very curious what the significance of the archive bit is expected to
> be.

Well, maybe I should have explained a bit further that this was a question
meant for everybody. No actual expectations here. Sorry to mislead you.
I've never really used cygwin, so I have no idea how the permissions work
there. I was sort of wondering out loud if that might play a part,
file attributes as they are.


> I've chased this issue down further and the plot thickens a bit.
>
> My test program may or may not work as expected depending the directory
> in which it's run.  Further digging shows that if cygwin creates the
> directory, my test works.  If cmd.exe or some other program create the
> directory, then the test fails.
>
> I've been fooling around with cygwin getfacl/setfacl since that's where
> the difference appears to be...

I wonder if this helps:
http://www.cygwin.com/cygwin-ug-net/ntsec.html

> It's looking definitely like this is not really a mingw problem at all.

Well, yes. If the executable works in plain Windows, the fault must lie
within Cygwin.


--
Tuomo

... Please reply if you don't get this message


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Georg Nikodym]

On Aug 28, 2007, at 5:35, Tuomo Latto wrote:

>
> I wonder if this helps:
> http://www.cygwin.com/cygwin-ug-net/ntsec.html

Yes it helps a lot.  Setting CYGWIN to nontsec makes my problem go  
away completely.  Wow, do I feel like a big loser.

-g



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users