www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - MapViewOfFileEx: Not enough storage is available to process this

reply Andre Pany <andre s-e-a-p.de> writes:
Hi,

in my application I create a zip archive with a size of ~ 400 MB 
and after that I read the archive. While trying to read the 
archive, there is an error:

std.windows.syserror.WindowsException std\mmfile.d(267): 
MapViewOfFileEx: Not enough storage is available to process this 
command. (error 8)

0x0045B2AE in  safe void* std.windows.syserror.wenforce!(void*, 
immutable(char)[]).wenforce(void*, lazy immutable(char)[], 
immutable(char)[], uint)
0x0044F4D8 in std.mmfile.MmFile 
std.mmfile.MmFile.__ctor(immutable(char)[])

 From the source code I cannot see any issue. Do you have an idea 
what the issue
is causing?

void zipFolder(string archiveFilePath, string folderPath)
{
	import std.zip, std.file;
	import std.exception: enforce;
	import std.path: baseName;
	
	enforce(exists(folderPath) && isDir(folderPath));
	
	ZipArchive zip = new ZipArchive();
	string folderName = folderPath.baseName;

	foreach(entry; dirEntries(folderPath, SpanMode.depth))
	{
		if (!entry.isFile)
			continue;
			
		ArchiveMember am = new ArchiveMember();
		am.name = entry.name[folderPath.length + 1..$];
		am.expandedData(cast(ubyte[]) read(entry.name));
		zip.addMember(am);
	}
	
	void[] compressed_data = zip.build();
	write(archiveFilePath, compressed_data);
}

string[] listZipContent(string archiveFilePath)
{
	import std.zip, std.file, std.mmfile;
	auto mmfile = new MmFile(archiveFilePath); // <-- causing the 
issue
	auto zip = new ZipArchive(mmfile[]);
	string[] results;
	foreach (name, am; zip.directory)
		results ~= name;
	return results;
}

Kind regards
André
Jan 26
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 26/01/2018 12:16 PM, Andre Pany wrote:
 Hi,
 
 in my application I create a zip archive with a size of ~ 400 MB and 
 after that I read the archive. While trying to read the archive, there 
 is an error:
 
 std.windows.syserror.WindowsException std\mmfile.d(267): 
 MapViewOfFileEx: Not enough storage is available to process this 
 command. (error 8)
 
 0x0045B2AE in  safe void* std.windows.syserror.wenforce!(void*, 
 immutable(char)[]).wenforce(void*, lazy immutable(char)[], 
 immutable(char)[], uint)
 0x0044F4D8 in std.mmfile.MmFile std.mmfile.MmFile.__ctor(immutable(char)[])
 
  From the source code I cannot see any issue. Do you have an idea what 
 the issue
 is causing?
 
 void zipFolder(string archiveFilePath, string folderPath)
 {
      import std.zip, std.file;
      import std.exception: enforce;
      import std.path: baseName;
 
      enforce(exists(folderPath) && isDir(folderPath));
 
      ZipArchive zip = new ZipArchive();
      string folderName = folderPath.baseName;
 
      foreach(entry; dirEntries(folderPath, SpanMode.depth))
      {
          if (!entry.isFile)
              continue;
 
          ArchiveMember am = new ArchiveMember();
          am.name = entry.name[folderPath.length + 1..$];
          am.expandedData(cast(ubyte[]) read(entry.name));
          zip.addMember(am);
      }
 
      void[] compressed_data = zip.build();
      write(archiveFilePath, compressed_data);
 }
 
 string[] listZipContent(string archiveFilePath)
 {
      import std.zip, std.file, std.mmfile;
      auto mmfile = new MmFile(archiveFilePath); // <-- causing the issue
      auto zip = new ZipArchive(mmfile[]);
      string[] results;
      foreach (name, am; zip.directory)
          results ~= name;
      return results;
 }
 
 Kind regards
 André
Could be heap fragmentation to who knows what else assuming of course this is 32bit right? If so, 64bit is the answer.
Jan 26
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Friday, 26 January 2018 at 12:19:10 UTC, rikki cattermole 
wrote:
 Could be heap fragmentation to who knows what else assuming of 
 course this is 32bit right? If so, 64bit is the answer.
Thanks for the hint. 64bit solves the issue. Should I anyway create an issue? Kind regards André
Jan 26
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 26/01/2018 12:32 PM, Andre Pany wrote:
 On Friday, 26 January 2018 at 12:19:10 UTC, rikki cattermole wrote:
 Could be heap fragmentation to who knows what else assuming of course 
 this is 32bit right? If so, 64bit is the answer.
Thanks for the hint. 64bit solves the issue. Should I anyway create an issue? Kind regards André
No, everything is working as designed.
Jan 26