Dangling file handles
ManicQin
I have a handle for a file,
I open the file on the first write, I close the file only when the
program exits.
before each write I check if I have a valid handle && file exists, If
the file does not exist I close the handle and create a new one.
Now I spotted something wierd... if I delete the file, and dont close
the handle a few minutes after, the file re-apear in my directory read-
only and with share mode set to NULL I cant del the file or open or
anything until The first write to the file.
Is there any way to prevent the OS from creating this ghost file? even
though I keep a handle to him?
Sam of California
what more, but there is more. In other words, there is probably something
recreating the file, but it is not normal for Windows to do that. It is
likely impossible for anyone unfamiliar with the software unique to your
system to guess what is the problem.
"ManicQin" <Mani...@gmail.com> wrote in message
news:498347ed-a8d9-44dd...@d5g2000hsc.googlegroups.com...
ManicQin
<sam...@social.rr.com_change_social_to_socal> wrote:
> There is more to the story than you are providing. You probably do not know
> what more, but there is more. In other words, there is probably something
> recreating the file, but it is not normal for Windows to do that. It is
> likely impossible for anyone unfamiliar with the software unique to your
> system to guess what is the problem.
>
>
> news:498347ed-a8d9-44dd...@d5g2000hsc.googlegroups.com...
>
> > Hello all.
> > I have a handle for a file,
> > I open the file on the first write, I close the file only when the
> > program exits.
> > before each write I check if I have a valid handle && file exists, If
> > the file does not exist I close the handle and create a new one.
>
> > Now I spotted something wierd... if I delete the file, and dont close
> > the handle a few minutes after, the file re-apear in my directory read-
> > only and with share mode set to NULL I cant del the file or open or
> > anything until The first write to the file.
> > Is there any way to prevent the OS from creating this ghost file? even
> > though I keep a handle to him?
Ok so let me clarify some details.
I wrote a simple logger, At first I used to createFile and closeFile
for each writeLog command which turn to be a very Time consuming
operation.
I decided to stop with this method and only to create the file on
start (first log write) and to close on exit.
When I create the file I create it in a delete and read share mode.
there is no problem reading or deleting the file while working.
Our QA use the logger to test the system and before they do an
operation they delete the log files while the system is working.
After deleting the file, and before I Re-Creating the file
the file Re-Apears with no sharing rights (It cannot be deleted or
opened)
(and I think that windows write that his size is the size before the
deletion)
Once the system writes a line to the log (i.e. closing the handle and
reopening the file) the "ghost" file vanishes.
The ghost file is not my hand creation. I'm certain of this. I tested
it back and forward and seen no call to createfile when the ghost file
apears.
As it seems, as long as I do not close the handle to the file, windows
keeps on holding the file even though it is deleted.
This behaviour creates a problem when our QA\clients tries to read
\send these Ghost files.
did anyone encounter this behaviour before? Is there any way to
disable it?
If not, can you suggest me with another way to handle files (A fast
way!)
Thanks Everyone!
(I'm going to post this in microsoft.public.win32.programmer.Kernel
too,
maybe they could shed some light on the subject)
Sam of California
>
> When I create the file I create it in a delete and read share mode.
> there is no problem reading or deleting the file while working.
Create how? What flags are you using?
> Our QA use the logger to test the system and before they do an
> operation they delete the log files while the system is working.
Delete how?
> After deleting the file, and before I Re-Creating the file
> the file Re-Apears with no sharing rights (It cannot be deleted or
> opened)
I don't understand "Re-Creating"; is the Create the same as above or
different? If different, what flags are used in the Re-Creating?
> As it seems, as long as I do not close the handle to the file, windows
> keeps on holding the file even though it is deleted.
That is probably normal. If this is the evidence that the file still exists
then the problem is different from what you describe.
> (I'm going to post this in microsoft.public.win32.programmer.Kernel
> too,
> maybe they could shed some light on the subject)
Be sure to mention this thread in the new thread.
ManicQin
>
> Create how? What flags are you using?
CreateFile((LPCTSTR)m_sFilePath, // pointer to name of the file
GENERIC_WRITE, // access (read-write) mode
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, // share
mode
NULL, // no security
OPEN_ALWAYS, // how to create
FILE_ATTRIBUTE_NORMAL, // file attributes
NULL);
> Delete how?
through windows explorer. the normal way
> I don't understand "Re-Creating"; is the Create the same as above or
> different? If different, what flags are used in the Re-Creating?
when I said Re-Create I meant that when Someone write to the log I
check if the file exists and if not I
call openlogfile again - same as the first file opened.
> That is probably normal. If this is the evidence that the file still exists
> then the problem is different from what you describe.
It is "normal" I am well aware of that.
It is not an OS bug and I think that the way I use the system could be
interpreted as a "misuse" of the system,
but if there's a way to "walk around" it I'd be happy to know.
Thanks!
Sam of California
>
> It is not an OS bug and I think that the way I use the system could be
> interpreted as a "misuse" of the system,
I doubt it is a misuse of the system. I suspect the problem is the result of
you assuming something that is not accurate. The problem with trying to help
is that it is difficult to know what is an innacurate assumption. I cannot
be sure everything you say is accurate since I know from personal experience
that it is possible to unintentionally be inaccurate simply by assuming.
The problem is complex and therefore difficult for you to describe. I wish I
could help more but I think the most important thing for you to do is to
verify assumptions. It is likely that something is happening that you don't
expect or something is not happening that you think is happening.
One thing I can say is that the way you are ensuring that the file exists
seems unusual. You can use flags to let Windows ensure that a file exists to
be written to. You seem to have code that is not necessary. Of course I
might misunderstand what you are doing and if so then it is frustrating to
not be able to help.
ManicQin
> seems unusual. You can use flags to let Windows ensure that a file exists to
> be written to. You seem to have code that is not necessary. Of course I
> might misunderstand what you are doing and if so then it is frustrating to
> not be able to help.
Lets do a simple test together
{{{
#include <windows.h>
int main()
{
DWORD dwWrittenToBuff = 30;
DWORD dwWrittenToFile = 0;
HANDLE m_hFile = CreateFile((LPCTSTR)"c:\\1.txt",
GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
NULL,
OPEN_ALWAYS,
FILE_ATTRIBUTE_NORMAL,
NULL);
WriteFile(m_hFile,
(LPCTSTR)"This is just a test",
dwWrittenToBuff,
&dwWrittenToFile,
NULL);
while (true)
{
Sleep(1000);
}
CloseHandle(m_hFile);
return 0;
}
}}}
1) copy paste and run
2) goto c:\ and delete 1.txt (program still running!)
3) press F5 (still running)
4) witness the resurrection of the 1.txt!
IT'S ALIVE!!! (da da daaam!!!) ;)
Sam of California
>
> Lets do a simple test together
> {{{
[code snipped]
> }}}
>
> 1) copy paste and run
> 2) goto c:\ and delete 1.txt (program still running!)
> 3) press F5 (still running)
> 4) witness the resurrection of the 1.txt!
> IT'S ALIVE!!! (da da daaam!!!) ;)
This is good. Simple samples such as that usually help.
I did as you said and the file does not get re-created for me. I do not
understand however why you have step 3 where F5 is used to start a new
instance but it does no matter whether I do that or not; either way, the
file is not re-created unless I terminate running instances after deleting
the file and then execute another instance.
ManicQin
<sam...@social.rr.com_change_social_to_socal> wrote:
> "ManicQin" <Manic...@gmail.com> wrote in message
>
> news:b4443ed0-688d-4a82...@d5g2000hsc.googlegroups.com...
>
>
>
> > Lets do a simple test together
> > {{{
>
> [code snipped]
>
> > }}}
>
> > 1) copy paste and run
> > 2) goto c:\ and delete 1.txt (program still running!)
> > 3) press F5 (still running)
> > 4) witness the resurrection of the 1.txt!
> > IT'S ALIVE!!! (da da daaam!!!) ;)
>
> This is good. Simple samples such as that usually help.
>
> I did as you said and the file does not get re-created for me. I do not
> understand however why you have step 3 where F5 is used to start a new
> instance but it does no matter whether I do that or not; either way, the
I meant F5 - Refresh... in the explorer window...
> file is not re-created unless I terminate running instances after deleting
> the file and then execute another instance.
That's naturally...
Wierd... I reproduced it in three computers, What is your OS?
Sam of California
I am using XP.
When I do the F5 in Windows Explorer after deleting the file, I do get the
file showing again. If I try to delete it a second time, I get Access
Denied. The file goes away when I exit the program. So it is unexpected
behavior but you are doing something that Windows does not expect.
So just don't use FILE_SHARE_DELETE. That is not normal. If it is used then
expect unusal occurances.
ManicQin
> I am using XP.
>
> When I do the F5 in Windows Explorer after deleting the file, I do get the
> file showing again. If I try to delete it a second time, I get Access
> Denied. The file goes away when I exit the program. So it is unexpected
> behavior but you are doing something that Windows does not expect.
>
> So just don't use FILE_SHARE_DELETE. That is not normal. If it is used then
> expect unusal occurances.
As I said... All share mode are revoked - It's the result of the
system marking the file for deletion but not deleting it as long as I
dont release the handle.
I'm must use FILE_SHARE_DELETE I wouldnt be able to delete the file
while the system works if I revoke the FILE_SHARE_DELETE...
Sam of California
Then the sample code you provided is not representative of the problem.
In the sample code and using the instructions provided with it. the file is
opened with FILE_SHARE_DELETE. The instructions you provided says to delete
the file while the program is still executing; the file is at that time
still open using FILE_SHARE_DELETE. If that is not what is happening in your
original program, then the sample you provided is useless for the purpose of
diagnosing the problem.
ManicQin
> Then the sample code you provided is not representative of the problem.
>
> In the sample code and using the instructions provided with it. the file is
> opened with FILE_SHARE_DELETE. The instructions you provided says to delete
> the file while the program is still executing; the file is at that time
> still open using FILE_SHARE_DELETE. If that is not what is happening in your
> original program, then the sample you provided is useless for the purpose of
> diagnosing the problem.
The revoking of share modes is in consequence of the delete and not my
code.
most of the code here was copy pasted from the project.
Thanks for the time you spent.
After reading some place else about it I can conclude that It is not a
bug.
It's a misuse but will have to live with it
thanks