Thread overview
MapViewOfFileEx: Not enough storage is available to process this command.
Jan 26, 2018
Andre Pany
Jan 26, 2018
rikki cattermole
Jan 26, 2018
Andre Pany
Jan 26, 2018
rikki cattermole
January 26, 2018
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é


January 26, 2018
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.
January 26, 2018
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é
January 26, 2018
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.