Re: Regarding CloseHandle() on Memory Map File
- From: "Hector Santos" <nospamhere@xxxxxxxxxxxxxx>
- Date: Mon, 4 Jul 2005 00:00:20 -0400
This is a follow up:
Now that I am thinking about this, I am pretty sure I recall some reference
to a Microsoft service pack fix that addressed some network write/flushing
caching optimization issues. What I don't recall it specifically mentioned
the file attributes such as:
FILE_FLAG_RANDOM_ACCESS
FILE_FLAG_SEQUENTIAL_SCAN
This caused two issues; A) an errorneous ERROR_ALREADY_EXIST error when you
didn't expect it or B) no ERROR_ALREADY_EXIST when you did expect it.
In other words, a bug. :-)
I just wrote a quick program to repeat the problem.. I had no problem going
across drives to XP and 2000 machnes, but on run across to an legacy NT 4.0
machine, I was able to reproduce it.
With this program below, you would be able to see the issue if you have the
same problem on your OS network. It always works fine on local machine
files.
Testing Goal:
1) If the file exist, you MUST get ERROR_ALREADY_EXIST.
2) If the file does not exist, you MUST NOT get ERROR_ALREADY_EXIST
3) If you get the unexpected error, try removing the file attibute.
Source code:
// FileName: TestExistBug.cpp
// Compile: cl testexistbug.cpp /W3 /GX /MD /D "_AFXDLL"
#include <stdio.h>
#include <afx.h>
void main(char argc, char *argv[])
{
char *szfile = "q:\\testing\\foobar1.dat"; // network file
// DeleteFile(szfile);
DWORD nFlags = 0;
nFlags |= FILE_ATTRIBUTE_NORMAL;
nFlags |= FILE_FLAG_RANDOM_ACCESS;
HANDLE hFile = CreateFile(szfile, GENERIC_READ|GENERIC_WRITE,
0,
NULL,
OPEN_ALWAYS,
nFlags,
NULL);
int err = GetLastError();
printf("hFile: %d Error: %d\n",hFile, err);
if (hFile != INVALID_HANDLE_VALUE) {
CloseHandle(hFile);
}
}
Let us know what you find on your setup.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
"Hector Santos" <nospamhere@xxxxxxxxxxxxxx> wrote in message
news:uPyktLEgFHA.3232@xxxxxxxxxxxxxxxxxxxxxxx
> Pawan,
>
> I didn't read the entire thread so I don't know if anything of my comments
> here was already touched on, but here is my experience here.
>
> For us, the end result was that there was OS networking drivers that
created
> erroneous ERROR_ALREADY_EXISTS, especially going across the network
> depending on the File Attributes for the CreateFile() function.
>
> This was an old issue dating back to 2000 when it was found. A logical
work
> around was added, so I don't know if the errors still persist today and
> would be surprise if it still does. I do know it was reported to
Microsoft
> when it was first found.
>
> For our mapfile in this case, the first time the file is created, a
header
> is written to it, but only if it didn't exist. So once the file was open
> with OpenAlways, it was important to know if the file already existed.
>
> For example:
>
> BOOL TMyMapFileClass::Open(const char *fn)
> {
> DWORD nFlags = 0;
> nFlags |= FILE_ATTRIBUTE_NORMAL;
> nFlags |= FILE_FLAG_RANDOM_ACCESS,
>
> hFile = CreateFile(fn, GENERIC_READ|GENERIC_WRITE,
> 0,
> NULL,
> OPEN_ALWAYS,
> nFlags, 0);
>
> int err = GetLastError();
> if (hFile == INVALID_HANDLE_VALUE) {
> return FALSE;
> }
>
> ZeroMemory(&HashTable, sizeof(HashTable));
>
> // v5.6.450.2, HLS, 12/20/00
> // don't check error - fixes cross network bug
>
> if (/* err != ERROR_ALREADY_EXISTS || */
> GetFileSize(hFile, NULL) == 0) {
> WriteAt(0, HashTable, sizeof(HashTable));
> }
> ReadAt(0, HashTable, sizeof(HashTable));
> return TRUE;
> }
>
> Now, I can't 100% recall, but I pretty such when it was finally figure
out,
> it was one of the nFlags file attributes that caused the erroneous error
and
> only happen, in this case, when the file was across the network.
>
> So if all possible try to see why the ERROR_ALREADY_EXIST is created for
> you. There is no "randomness" to this. No Timing issue. Its a bug
> somewhere. Either you expect this error or you don't.
>
> See if the file attribute is causing it for you.
>
> I'll be interested to know what you find.
>
> --
> Hector Santos, Santronics Software, Inc.
> http://www.santronics.com
>
>
>
>
>
>
> "Pawan." <Pawan@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:2319A458-D293-41B8-A921-0F757D502192@xxxxxxxxxxxxxxxx
> > Hi,
> >
> > I am facing a problem related to Memory map files. I have an application
> > which creates a file mapping and other applications map that file in its
> > virtual memory. And unmaps the view as soon as the work is over.
> > The creator of the Mapping file unmaps it from its view and call the
> > CloseHandle().
> > The problem is if the same memory map file name is used to create the
file
> > it sometimes gives error that the map file already exists
> > (ERROR_ALREADY_EXISTS). My question is what is the time difference
> between
> > CloseHandle() and actually closing the mapfile (reclaiming the memory).
> And
> > is there a way to tune it or instruct the OS to immediately reclaim the
> > memory.
> > I am using Win2000 and MSVC7.0.
> >
> > Thanks in Advance,
> >
> > Pawan Waghalkar,
> > Software Engg.
> > India.
>
.
- Follow-Ups:
- Re: Regarding CloseHandle() on Memory Map File
- From: Pawan.
- Re: Regarding CloseHandle() on Memory Map File
- References:
- Regarding CloseHandle() on Memory Map File
- From: Pawan.
- Re: Regarding CloseHandle() on Memory Map File
- From: Hector Santos
- Regarding CloseHandle() on Memory Map File
- Prev by Date: Re: Regarding CloseHandle() on Memory Map File
- Next by Date: IPC using Callback?
- Previous by thread: Re: Regarding CloseHandle() on Memory Map File
- Next by thread: Re: Regarding CloseHandle() on Memory Map File
- Index(es):
Relevant Pages
|
