Re: mingw: pwd.h and grp.h functions, uid_t, getuid, chown, fork, etc

[Bruno Haible]

Hi Simon,

> Generally, I think it would be nice to identify all modules that doesn't
> work under mingw yet.

Last time I checked, I needed
  --avoid=savewd --avoid=mkancesdirs --avoid=mkdir-p --avoid=getugroups 
--avoid=idcache --avoid=userspec
in order to get a successful build on mingw. Your autobuild is certainly more
up-to-date.

> Maybe they should even be disabled by default,
> when cross-compiled to mingw?

How would that work? gnulib-tool helps piecing together a package, and the
decision whether to build on Unix or on mingw comes later. If that package
intends to be portable to mingw, it cannot use 'savewd' ... 'userspec'.

> 1) pwd.h user handling functions including chown
> 
> Is there any chance to implement a replacement pwd.h or grp.h header
> that will be useful on mingw?
> 
> As far as I can tell from MSDN documentation, Windows doesn't have any
> numeric user identity concept.  I may be wrong though, as I'm not a
> Windows programmer.
> 
> If I'm correct, most if not all of the pwd.h and grp.h types and
> functions becomes impossible to adapt.  See the POSIX documentation:
> 
> http://www.opengroup.org/onlinepubs/009695399/basedefs/pwd.h.html
> http://www.opengroup.org/onlinepubs/009695399/basedefs/grp.h.html
> 
> Maybe we could provide pwd.h and grp.h header files that does something
> like:
> 
> # undef getuid
> # define getuid() \
>     (GL_LINK_WARNING ("getuid is not supported under mingw"), \
>      getuid ())
> 
> It may be possible to provide dummy functions on mingw for some
> functions, for example:
> 
> int chown (const char *path, uid_t owner, gid_t group)
> {
>   errno = ENOSYS;
>   return -1;
> }
> 
> This requires defining uid_t and gid_t to some reasonable type though.
> 
> I wonder if these kind of replacements are useful

I don't think they would be very useful, because there are two reasons
to code user / file owner related things differently on native Windows
than on Unix:
  1) uid_t can be at most 64 bits. Do you know of a mapping from
     Windows SID to such a number that would be independent of the
     process running on a particular machine?
  2) While on Unix, you get the uid and gid of a file for free during stat(),
     on Windows they are quite expensive. (I once wrote a program which
     displayed a directory hierarchy graphically, with a specific colour
     for each different file owner uid. The effort to look up the SID of
     every file, using GetSecurityInfo, LookupAccountSid,
     ConvertSidToStringSid, was larger than the effort to get the size and
     other attributes.

> It can be useful to find out the current user's username though, and
> this is possible under Windows (i.e., GetUserName).  In GNU SASL, the
> only reason I use pwd.h is to get the user's username.  So it may be
> sufficient to provide a wrapper function for this particular purpose
> only?  On the other hand, that would result in using non-POSIX interface
> to do something for which there is POSIX functions for, which I dislike.

Yes, this is exactly the problem we are facing here.

> 2) fork
> 
> This is needed by spawni.c and savewd.c only.
> 
> Possibly the spawni.c usage could be ported to Windows, supported on a
> best effort basis?

I'm working on that, but it's slow going...

Bruno