From b283470e51ec47dfbed5fc3685e3b4b60b028a3c Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Fri, 4 Apr 2014 14:26:05 +0000 Subject: [PATCH] * ntea.cc (EA_BUFSIZ): Fix comment. (read_ea): Use tmp_pathbuf for local buffer rather than alloca. Throughout change ZwQueryEaFile to NtQueryEaFile in comments. --- winsup/cygwin/ChangeLog | 8 +++++++- winsup/cygwin/ntea.cc | 26 ++++++++++++++------------ 2 files changed, 21 insertions(+), 13 deletions(-) diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog index 81d216b3b..e6ea8b4cc 100644 --- a/winsup/cygwin/ChangeLog +++ b/winsup/cygwin/ChangeLog @@ -1,6 +1,12 @@ 2014-04-04 Corinna Vinschen - * ntea (EA_BUFSIZ): Reduce to 64K. Add comment to explain why. + * ntea.cc (EA_BUFSIZ): Fix comment. + (read_ea): Use tmp_pathbuf for local buffer rather than alloca. + Throughout change ZwQueryEaFile to NtQueryEaFile in comments. + +2014-04-04 Corinna Vinschen + + * ntea.cc (EA_BUFSIZ): Reduce to 64K. Add comment to explain why. 2014-03-29 Christopher Faylor diff --git a/winsup/cygwin/ntea.cc b/winsup/cygwin/ntea.cc index 34d70d00d..2fb205a04 100644 --- a/winsup/cygwin/ntea.cc +++ b/winsup/cygwin/ntea.cc @@ -17,6 +17,7 @@ details. */ #include "dtable.h" #include "cygheap.h" #include "ntdll.h" +#include "tls_pbuf.h" #include #include @@ -24,17 +25,17 @@ details. */ #define MAX_EA_VALUE_LEN 65536 /* At least one maximum sized entry fits. - CV 2014-04-04: I'm really puzzled how it should be possible to have 64K EAs, - if the NtQueryEaFile function chokes on buffers bigger than - 64K with STATUS_INVALID_PARAMETER, at least on Windows 7 and - later. In theory, the buffer size should be + CV 2014-04-04: NtQueryEaFile function chokes on buffers bigger than 64K + with STATUS_INVALID_PARAMETER if the handle points to a file + on a remote share, at least on Windows 7 and later. + In theory the buffer should have a size of - (sizeof (FILE_FULL_EA_INFORMATION) + MAX_EA_NAME_LEN + sizeof (FILE_FULL_EA_INFORMATION) + MAX_EA_NAME_LEN + MAX_EA_VALUE_LEN - to read a single 64K EA. But maybe I just misunderstood and - EAs can't be 64K. I can't find the source I got this - information from anymore. */ + (65804 bytes), but we're opting for simplicity here, and + a 64K buffer has the advantage that we can use a tmp_pathbuf + buffer, rather than having to alloca 64K from stack. */ #define EA_BUFSIZ MAX_EA_VALUE_LEN #define NEXT_FEA(p) ((PFILE_FULL_EA_INFORMATION) (p->NextEntryOffset \ @@ -51,8 +52,9 @@ read_ea (HANDLE hdl, path_conv &pc, const char *name, char *value, size_t size) ULONG glen = 0; PFILE_GET_EA_INFORMATION gea = NULL; PFILE_FULL_EA_INFORMATION fea; + tmp_pathbuf tp; /* We have to store the latest EaName to compare with the next one, since - ZwQueryEaFile has a bug when accessing files on a remote share. It + NtQueryEaFile has a bug when accessing files on a remote share. It returns the last EA entry of the file infinitely. Even utilizing the optional EaIndex only helps marginally. If you use that, the last EA in the file is returned twice. */ @@ -82,7 +84,7 @@ read_ea (HANDLE hdl, path_conv &pc, const char *name, char *value, size_t size) hdl = NULL; } - fea = (PFILE_FULL_EA_INFORMATION) alloca (EA_BUFSIZ); + fea = (PFILE_FULL_EA_INFORMATION) tp.w_get (); if (name) { @@ -158,10 +160,10 @@ read_ea (HANDLE hdl, path_conv &pc, const char *name, char *value, size_t size) } if (name) { - /* Another weird behaviour of ZwQueryEaFile. If you ask for a + /* Another weird behaviour of NtQueryEaFile. If you ask for a specific EA which is not present in the file's EA list, you don't get a useful error code like STATUS_NONEXISTENT_EA_ENTRY. Rather - ZwQueryEaFile returns success with the entry's EaValueLength + NtQueryEaFile returns success with the entry's EaValueLength set to 0. */ if (!fea->EaValueLength) { -- 2.43.5