bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
* [PATCH] stat: implement GetFileInformationByHandle with Winstore apps restrictions
@ 2020-05-19 10:49 Steve Lhomme
  2020-05-30  9:41 ` Bruno Haible
  0 siblings, 1 reply; 7+ messages in thread
From: Steve Lhomme @ 2020-05-19 10:49 UTC (permalink / raw)
  To: bug-gnulib; +Cc: Steve Lhomme

GetFileInformationByHandle() cannot be called. But the same information can be
gathered via calls to GetFileInformationByHandleEx() which is allowed.

A function pointer is used to pick between the local version using
GetFileInformationByHandleEx() and the system one.

If WINSTORECOMPAT is defined that means the app is built with mingw including
the compatibility library which also includes an GetFileInformationByHandle()
implementation, so no need to redefine it.
---
 lib/stat-w32.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/lib/stat-w32.c b/lib/stat-w32.c
index 6900dfcf5..6699b9560 100644
--- a/lib/stat-w32.c
+++ b/lib/stat-w32.c
@@ -58,6 +58,48 @@ typedef DWORD (WINAPI * GetFinalPathNameByHandleFuncType) (HANDLE hFile,
 static GetFinalPathNameByHandleFuncType GetFinalPathNameByHandleFunc = NULL;
 static BOOL initialized = FALSE;
 
+#if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP) && !defined(WINSTORECOMPAT)
+WINBOOL _GetFileInformationByHandle(HANDLE hFile, LPBY_HANDLE_FILE_INFORMATION lpInfo)
+{
+    FILE_ID_INFO id_info;
+    FILE_STANDARD_INFO standard_info;
+    FILE_BASIC_INFO basic_info;
+    if (!GetFileInformationByHandleEx(hFile, FileIdInfo, &id_info, sizeof (id_info)) ||
+        !GetFileInformationByHandleEx(hFile, FileStandardInfo, &standard_info, sizeof (standard_info)) ||
+        !GetFileInformationByHandleEx(hFile, FileBasicInfo, &basic_info, sizeof (basic_info)))
+    {
+        return FALSE;
+    }
+    
+    lpInfo->dwFileAttributes = basic_info.FileAttributes;
+
+    lpInfo->ftCreationTime.dwHighDateTime   = basic_info.CreationTime.HighPart;
+    lpInfo->ftCreationTime.dwLowDateTime    = basic_info.CreationTime.LowPart;
+    lpInfo->ftLastAccessTime.dwHighDateTime = basic_info.LastAccessTime.HighPart;
+    lpInfo->ftLastAccessTime.dwLowDateTime  = basic_info.LastAccessTime.LowPart;
+    lpInfo->ftLastWriteTime.dwHighDateTime  = basic_info.LastWriteTime.HighPart;
+    lpInfo->ftLastWriteTime.dwLowDateTime   = basic_info.LastWriteTime.LowPart;
+
+    lpInfo->dwVolumeSerialNumber = id_info.VolumeSerialNumber;
+
+    lpInfo->nFileSizeHigh = standard_info.EndOfFile.HighPart;
+    lpInfo->nFileSizeLow  = standard_info.EndOfFile.LowPart;
+
+    lpInfo->nNumberOfLinks = standard_info.NumberOfLinks;
+
+    /* The nFileIndex from GetFileInformationByHandle is equal to the low
+             64 bits of the 128-bit FileId from GetFileInformationByHandleEx,
+             and the high 64 bits of this 128-bit FileId are zero. */
+    lpInfo->nFileIndexLow  = (id_info.FileId.Identifier[12] << 24) | (id_info.FileId.Identifier[13] << 16) | (id_info.FileId.Identifier[14] << 8) | id_info.FileId.Identifier[15];
+    lpInfo->nFileIndexHigh = (id_info.FileId.Identifier[ 8] << 24) | (id_info.FileId.Identifier[ 9] << 16) | (id_info.FileId.Identifier[10] << 8) | id_info.FileId.Identifier[11];
+
+    return TRUE;
+}
+static WINBOOL (*GetFileInformationByHandleFunc)(HANDLE hFile, LPBY_HANDLE_FILE_INFORMATION lpInfo) = _GetFileInformationByHandle;
+#else /* WINAPI_PARTITION_DESKTOP */
+static WINBOOL (WINAPI *GetFileInformationByHandleFunc)(HANDLE hFile, LPBY_HANDLE_FILE_INFORMATION lpInfo) = GetFileInformationByHandle;
+#endif /* WINAPI_PARTITION_DESKTOP */
+
 static void
 initialize (void)
 {
@@ -159,7 +201,7 @@ _gl_fstat_by_handle (HANDLE h, const char *path, struct stat *buf)
          <https://docs.microsoft.com/en-us/windows/desktop/api/winbase/ns-winbase-_file_basic_info>
          The latter requires -D_WIN32_WINNT=_WIN32_WINNT_VISTA or higher.  */
       BY_HANDLE_FILE_INFORMATION info;
-      if (! GetFileInformationByHandle (h, &info))
+      if (! GetFileInformationByHandleFunc (h, &info))
         goto failed;
 
       /* Test for error conditions before starting to fill *buf.  */
-- 
2.26.2



^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] stat: implement GetFileInformationByHandle with Winstore apps restrictions
  2020-05-19 10:49 [PATCH] stat: implement GetFileInformationByHandle with Winstore apps restrictions Steve Lhomme
@ 2020-05-30  9:41 ` Bruno Haible
  2020-05-30 13:57   ` Steve Lhomme
  0 siblings, 1 reply; 7+ messages in thread
From: Bruno Haible @ 2020-05-30  9:41 UTC (permalink / raw)
  To: bug-gnulib; +Cc: Steve Lhomme

Hi,

Steve Lhomme wrote:
> GetFileInformationByHandle() cannot be called. But the same information can be
> gathered via calls to GetFileInformationByHandleEx() which is allowed.

I am understanding from [1] that Microsoft is augmenting the list of allowed
functions in UWP over time, and that ultimately most Windows API functions will
be allowed in UWP in the end, because "developers want the Windows API".

So, it makes sense to put your code into a separate library, that implements
Windows API on top of UWP API. Gnulib focuses (partially) on providing the
POSIX and glibc API on top of the Windows API.

The two, that is the Windows API emulation on top of UWP API and Gnulib, ought
to work seamlessly together (assuming that other library does not have GPL-
incompatible license terms).

Bruno

[1] https://www.thurrott.com/dev/206351/microsoft-confirms-uwp-is-not-the-future-of-windows-apps



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] stat: implement GetFileInformationByHandle with Winstore apps restrictions
  2020-05-30  9:41 ` Bruno Haible
@ 2020-05-30 13:57   ` Steve Lhomme
  2020-05-30 14:35     ` Bruno Haible
  0 siblings, 1 reply; 7+ messages in thread
From: Steve Lhomme @ 2020-05-30 13:57 UTC (permalink / raw)
  To: Bruno Haible, bug-gnulib

> On May 30, 2020 11:41 AM Bruno Haible <bruno@clisp.org> wrote:
> 
>  
> Hi,
> 
> Steve Lhomme wrote:
> > GetFileInformationByHandle() cannot be called. But the same information can be
> > gathered via calls to GetFileInformationByHandleEx() which is allowed.
> 
> I am understanding from [1] that Microsoft is augmenting the list of allowed
> functions in UWP over time, and that ultimately most Windows API functions will
> be allowed in UWP in the end, because "developers want the Windows API".

Yes, they did add a lot of allowed API's between Win8 and Win10. But it's far from the full API. A lot of API's are deprecated and they use that opportunity to get rid of some old stuff. That's the same deal with the Universal C Runtime which removed a lot of insecure calls. I think it's more likely some of the old API's will not work in the future rather than allowing more and more people to use it.
This API set is the one to use on Xbox for example. And it's not going away, nor are they going to add some more old stuff.
 
> So, it makes sense to put your code into a separate library, that implements
> Windows API on top of UWP API. Gnulib focuses (partially) on providing the
> POSIX and glibc API on top of the Windows API.

That's the case in mingw-w64 which has winstorecompat to mimick some of the forbidden APIs without having to recompile the code:
https://github.com/mirror/mingw-w64/tree/master/mingw-w64-libraries/winstorecompat

You can see one of the last commit is adding GetFileInformationByHandle() for example. But that means anyone building with an older version of winstorecompat cannot rely on this helper.

> The two, that is the Windows API emulation on top of UWP API and Gnulib, ought
> to work seamlessly together (assuming that other library does not have GPL-
> incompatible license terms).
> 
> Bruno
> 
> [1] https://www.thurrott.com/dev/206351/microsoft-confirms-uwp-is-not-the-future-of-windows-apps


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] stat: implement GetFileInformationByHandle with Winstore apps restrictions
  2020-05-30 13:57   ` Steve Lhomme
@ 2020-05-30 14:35     ` Bruno Haible
  2020-05-30 14:51       ` Steve Lhomme
  0 siblings, 1 reply; 7+ messages in thread
From: Bruno Haible @ 2020-05-30 14:35 UTC (permalink / raw)
  To: Steve Lhomme; +Cc: bug-gnulib

Steve Lhomme wrote:
> > So, it makes sense to put your code into a separate library, that implements
> > Windows API on top of UWP API. Gnulib focuses (partially) on providing the
> > POSIX and glibc API on top of the Windows API.
> 
> That's the case in mingw-w64 which has winstorecompat to mimick some of the forbidden APIs without having to recompile the code:
> https://github.com/mirror/mingw-w64/tree/master/mingw-w64-libraries/winstorecompat

Thanks for confirming that such a library already exists!

> You can see one of the last commit is adding GetFileInformationByHandle() for example. But that means anyone building with an older version of winstorecompat cannot rely on this helper.

That's not a good enough reason for adding this code to gnulib.

Bruno



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] stat: implement GetFileInformationByHandle with Winstore apps restrictions
  2020-05-30 14:35     ` Bruno Haible
@ 2020-05-30 14:51       ` Steve Lhomme
  2020-05-30 15:47         ` Bruno Haible
  0 siblings, 1 reply; 7+ messages in thread
From: Steve Lhomme @ 2020-05-30 14:51 UTC (permalink / raw)
  To: Bruno Haible; +Cc: bug-gnulib

> On May 30, 2020 4:35 PM Bruno Haible <bruno@clisp.org> wrote:
> 
>  
> Steve Lhomme wrote:
> > > So, it makes sense to put your code into a separate library, that implements
> > > Windows API on top of UWP API. Gnulib focuses (partially) on providing the
> > > POSIX and glibc API on top of the Windows API.
> > 
> > That's the case in mingw-w64 which has winstorecompat to mimick some of the forbidden APIs without having to recompile the code:
> > https://github.com/mirror/mingw-w64/tree/master/mingw-w64-libraries/winstorecompat
> 
> Thanks for confirming that such a library already exists!
> 
> > You can see one of the last commit is adding GetFileInformationByHandle() for example. But that means anyone building with an older version of winstorecompat cannot rely on this helper.
> 
> That's not a good enough reason for adding this code to gnulib.

I agree. But there should be a way to compile gnulib without calling the forbidden/old/deprecated API's. That's currently not possible. For example in stat-w32.c the "_GL_WINDOWS_STAT_INODES == 2" mode is not enabled yet. And even then it would still do a call GetFileInformationByHandle() which will not link in the end. (in mingw-w64 it will because they don't builds libs for UWP/not-UWP)


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] stat: implement GetFileInformationByHandle with Winstore apps restrictions
  2020-05-30 14:51       ` Steve Lhomme
@ 2020-05-30 15:47         ` Bruno Haible
  2020-05-30 16:37           ` Steve Lhomme
  0 siblings, 1 reply; 7+ messages in thread
From: Bruno Haible @ 2020-05-30 15:47 UTC (permalink / raw)
  To: Steve Lhomme; +Cc: bug-gnulib

Steve Lhomme wrote:
> > > You can see one of the last commit is adding GetFileInformationByHandle() for example. But that means anyone building with an older version of winstorecompat cannot rely on this helper.
> > 
> > That's not a good enough reason for adding this code to gnulib.
> 
> I agree. But there should be a way to compile gnulib without calling the forbidden/old/deprecated API's. That's currently not possible. For example in stat-w32.c the "_GL_WINDOWS_STAT_INODES == 2" mode is not enabled yet. And even then it would still do a call GetFileInformationByHandle() which will not link in the end. (in mingw-w64 it will because they don't builds libs for UWP/not-UWP)

It should link fine if you use the 'winstorecompat' library that you mentioned.
If it doesn't, it's a problem with that library, not with Gnulib.

Bruno



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] stat: implement GetFileInformationByHandle with Winstore apps restrictions
  2020-05-30 15:47         ` Bruno Haible
@ 2020-05-30 16:37           ` Steve Lhomme
  0 siblings, 0 replies; 7+ messages in thread
From: Steve Lhomme @ 2020-05-30 16:37 UTC (permalink / raw)
  To: Bruno Haible; +Cc: bug-gnulib

> On May 30, 2020 5:47 PM Bruno Haible <bruno@clisp.org> wrote:
> 
>  
> Steve Lhomme wrote:
> > > > You can see one of the last commit is adding GetFileInformationByHandle() for example. But that means anyone building with an older version of winstorecompat cannot rely on this helper.
> > > 
> > > That's not a good enough reason for adding this code to gnulib.
> > 
> > I agree. But there should be a way to compile gnulib without calling the forbidden/old/deprecated API's. That's currently not possible. For example in stat-w32.c the "_GL_WINDOWS_STAT_INODES == 2" mode is not enabled yet. And even then it would still do a call GetFileInformationByHandle() which will not link in the end. (in mingw-w64 it will because they don't builds libs for UWP/not-UWP)
> 
> It should link fine if you use the 'winstorecompat' library that you mentioned.
> If it doesn't, it's a problem with that library, not with Gnulib.

It wouldn't until a few days ago before I patched it. Anyone using mingw 7.0 (ie all current Linux distros) will not be able to use it until there's a release.

And this library exists for legacy code that cannot be changed. I don't think gnulib falls in this category. And ultimately that library should not be used at all.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-05-30 16:38 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-19 10:49 [PATCH] stat: implement GetFileInformationByHandle with Winstore apps restrictions Steve Lhomme
2020-05-30  9:41 ` Bruno Haible
2020-05-30 13:57   ` Steve Lhomme
2020-05-30 14:35     ` Bruno Haible
2020-05-30 14:51       ` Steve Lhomme
2020-05-30 15:47         ` Bruno Haible
2020-05-30 16:37           ` Steve Lhomme

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).