More crufty stuff, yes, it was my bug, and no, this is really horked since

  we aren't distinguishing the size of the file backing the mmap from the
  size of the mmap'ed view.


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@61806 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 6 insertions, 3 deletions

diff --git a/mmap/win32/mmap.c b/mmap/win32/mmap.c
index cab53992d..8a27618ee 100644
--- a/mmap/win32/mmap.c
+++ b/mmap/win32/mmap.c
@@ -126,11 +126,14 @@ APR_DECLARE(apr_status_t) apr_mmap_create(apr_mmap_t **new, apr_file_t *file,
     (*new)->pstart = (offset / memblock) * memblock;
     (*new)->psize = (apr_size_t)(offset % memblock) + size;
     (*new)->poffset = offset - (*new)->pstart;
-    offlo = (DWORD)(*new)->psize;
-    offhi = (DWORD)((*new)->psize << 32);
+    /* XXX: psize below should be the MAXIMUM size of the mmap object,
+     * (e.g. file size) not the size of the mapped region!
+     * Since apr doesn't seem to acknowledge the discrepancy (the mmap
+     * size/view/off concepts are pretty horked) this will have to wait.
+     */
 
     (*new)->mhandle = CreateFileMapping(file->filehand, NULL, fmaccess,
-                                        offhi, offlo, NULL);
+                                        0, (*new)->psize, NULL);
     if (!(*new)->mhandle || (*new)->mhandle == INVALID_HANDLE_VALUE)
     {
         *new = NULL;