Thanks Bruno for such detailed notes. I will start to work on cleaning up the patches to prep for the mailing list.
> When a package has complicated fork/exec logic, generally it's advisable to > use the posix_spawn facility when possible. This provides not only portability > to native Windows; it is also a speedup on GNU/Linux (because glibc implements > posix_spawn through optimized clone() syscalls). Exactly what I try to do. Right now I generally #ifdef'd the fork/exec changes to _WIN32 even though (as you mentioned) posix_spawn should be better for all platforms. As I go through and submit patches to other projects though if they are good to remove the old fork code certainly am working to write the posix_spawn code in a platform agnostic fashion. Without a doubt replacing the fork code is often some of the most complex. > Support for native Windows symlinks is something that Gnulib does not have > so far. The complexity of the several kinds of "reparse points" is not > something that invites developers to support it... It is true that Windows historically hasn't had great symbolic and hard linking api's / compatibility but the largest barriers were largely removed back in 2016 with all in-support versions of Windows having full symbolic link support without any special developer options/admin requirements. For the most part Windows support mirrors that of *nix platforms now with 3 key variances: 1) Directory symbolic links are distinct from file symbolic links. While I could have the API cover this up as it can be important I try to return what seemed the most true representation. S_DIR does return true for symbolic directory links and the new S_HARDDIR returns true if the directory is not a symbolic link. This seemed most intuitive in most situations. The primary exception is code that switches on the file system entry and checks S_DIR before S_SYMLINK may need those things reversed. 2) While Windows supports normal volume symlinks like c:/some/dir it also supports using the volume GUID in place of the drive letter. This however is not a format that can be seamlessly handled by most applications not expecting it so is not returned by default. 3) Windows still has "directory junctions" left over which are similar to directory symbolic links. They differ mostly in terms of resolution in remote file share situations. These I return information on as if they are standard directory symlinks and do not provide a way to create (as the concept doesn't really exist in *nix). This is similar to how Windows native renders directory junctions / directory sym links in most situations. > In Gnulib, we use > #if defined _WIN32 && !defined __CYGWIN__ If I understand correctly anywhere I am using _WIN32 I should update it to this dual check as cygwin may have this _WIN32 definition but it should be treated not as _WIN32. > Yes, that's an adaptation that needs be made in the packages: When the > package requests a polyfill for function XY (and this polyfill is always > available), tests of HAVE_XY should be simplified to 1. Developers like > this, because it makes their code easier. I don't think you are saying this should automatically happen (similar to in GNULIB where most of the preprocessor directives are replaced at configure time with 1s and 0s). I assume more so that they should manually be removing the HAVE_XY test once they include the gnulib module? There are situations though that the polyfill won't work on some platforms. I guess my question is how would I best alter this code to account for where there _may_ be a polyfill. This even extends to things like some gnulib modules. In the symlinkat from gnulib it only checks HAVE_SYMLINK ( https://github.com/coreutils/gnulib/blob/master/lib/symlinkat.c#L50 ), and fails to provide a working solution without. With the symlink fixes I changed to make sure REPLACE_SYMLINK was defined and then to make sure both HAVE_SYMLINK and REPLACE_SYMLINK are false before the fail function. Another example, take GNU make. It has checks for HAVE_DIRENT_H in the code, but after including the proper gnulib modules there is essentially working directory enumeration code on Windows. It would seem odd to just remove all HAVE_DIRENT_H checks, right now I have often just done #if defined(HAVE_DIRENT_H) or defined(_WIN32). It is clear why gnulib internally would need things like HAVE_DIRENT_H (although many again are handled already by configure) but for anything outside of gnulib it would seem HAVE_DIRENT_H should have a value of 1 if it gets polyfilled by gnulib. ~mitch (they, them)
