Any issue with GetTempFileName() when temp folder has over 65K files?
Hector Santos
to be resolved when he finally found over 65K temp files in the current
window's user temp file and deleted them.
I'm trying to find out if this something related to our applet and we
could of picked up on.
The application is creating a temp file as so:
char path[MAX_PATH];
GetTempPath(sizeof(path), path);
GetTempFileName(path, "cgi", 0,szOutputFileName);
hfile = CreateFile(szOutputFileName,
GENERIC_WRITE,
FILE_SHARE_READ,
&sa,
CREATE_ALWAYS,
FILE_ATTRIBUTE_TEMPORARY|FILE_FLAG_SEQUENTIAL_SCAN,
NULL);
When the application is finished, its cleanup logic does:
if (hfile != INVALID_HANDLE_VALUE) CloseHandle(hfile);
if (szOutputFileName[0]) DeleteFile(szOutputFileName);
We don't have any error checking on the GetTempFileName() nor the
CreateFile() calls. That will be added.
But we never had a reported issue with this 10 year old logic until now
so I am wondering why this one customer had the problem when his temp
folder had over 65K files and he claims deleting them, fixed the problem
for him.
The only other thing that cross my mind is that there was some latency
issue with the CloseHandle() call and the DeleteFile() call failed.
Any comments?
Thanks in Advance
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
Hector Santos
The symptom of the problem was that the hfile handle is passed to a
subprocess for output. The applet reads the output. The symptom is that
the output is blank. Since we didn't have any error checking on the
creation of the handle (nor writing to it), we don't know if there was a
problem with the file name returned by GetTempFileName(). The customer
reported deleting the 65K temp files cured the problem and now he was
seeing output from the subprocess.
So I am trying to see if a) there is a issue with GetTempFileName() when
there already issue over 65K temp file names; and b) could there be an
explanation why the temp files were not deleted.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
"Hector Santos" <nospa...@nospamhere.com> wrote in message
Jochen Kalmbach [MVP]
> We don't have any error checking on the GetTempFileName() nor the
> CreateFile() calls. That will be added.
Bad idea...
> But we never had a reported issue with this 10 year old logic until now
> so I am wondering why this one customer had the problem when his temp
> folder had over 65K files and he claims deleting them, fixed the problem
> for him.
We had an issue, because one of our programmer forgot to delete the
temp-file ;-(
After several weeks the customer complained that the program does not
work anymore...
> The only other thing that cross my mind is that there was some latency
> issue with the CloseHandle() call and the DeleteFile() call failed.
If you delete the file correctly there should be no problem.
But if there are 64K cgiNNNN.tmp files (as you said) then
"GetTempFileName" will return an error, because it cannot create a
unique filename...
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Jochen Kalmbach [MVP]
> So I am trying to see if a) there is a issue with GetTempFileName() when
> there already issue over 65K temp file names;
If there are 0xFFFF files with the same prefix in the same dir, then
GetTempFileName will fail.
> could there be an
> explanation why the temp files were not deleted.
The file is a simple file, no special stuff...
Scherbina Vladimir
"Hector Santos" <nospa...@nospamhere.com> wrote in message
news:uAv%231iZKG...@TK2MSFTNGP10.phx.gbl...
Maybe FILE_FLAG_DELETE_ON_CLOSE flag will be usefull in this situation ? Let
the OS delete temp file itself.
>
> Any comments?
>
> Thanks in Advance
>
> --
> Hector Santos, Santronics Software, Inc.
> http://www.santronics.com
>
--
Vladimir
Hector Santos
Hi Jochen,
"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> wrote in
message
>> We don't have any error checking on the GetTempFileName() nor the
>> CreateFile() calls. That will be added.
> Bad idea...
What's a bad idea? Adding error checking? Please elaborate.
> We had an issue, because one of our programmer forgot to delete the
> temp-file ;-(
But we are deleting the file in our destructor class.
>> The only other thing that cross my mind is that there was
>> some latency issue with the CloseHandle() call and the
>> DeleteFile() call failed.
>
> If you delete the file correctly there should be no problem.
Right, and there wasn't for 10 years until this odd report from a
customer.
> But if there are 64K cgiNNNN.tmp files (as you said)
right and I assume that is what the customer meant....
> then "GetTempFileName" will return an error, because it
> cannot create a unique filename...
Ok, if assuming the file name is not initialized or defined, the
CreatFile should of failed and since no anticipated error logic was
added, this might explain why there was no sub-process output.
So next is to find out how he got such a built up. :-)
Like I said, the destructor is cleaning it up for normal conditions:
--- in destructor ---
if (hfile != INVALID_HANDLE_VALUE) CloseHandle(hfile);
if (szOutputFileName[0]) DeleteFile(szOutputFileName);
And just to double check... the constructor is initializing
szOutputFileName.
I guess I can add logic to check the result of GetTempFileName(), but
this doesn't explain why the files were not deleted.
Thanks Jochen
---
Hector
Jochen Kalmbach [MVP]
>>>We don't have any error checking on the GetTempFileName() nor the
>>>CreateFile() calls. That will be added.
>
>>Bad idea...
>
> What's a bad idea? Adding error checking? Please elaborate.
Sorry... I meant "don´t have any error checking"...
>>We had an issue, because one of our programmer forgot to delete the
>>temp-file ;-(
>
> But we are deleting the file in our destructor class.
But why does the customer had over 65K tmp-files?
> And just to double check... the constructor is initializing
> szOutputFileName.
Also the flag (FILE_FLAG_DELETE_ON_CLOSE) which Scherbian already
pointed out might be interesting.
Of course, today, there might also be problems with apps that hook API
functions...
Hector Santos
"Scherbina Vladimir" <vladimir....@gmail.com> wrote in message
>> hfile = CreateFile(szOutputFileName,
>> GENERIC_WRITE,
>> FILE_SHARE_READ,
>> &sa,
>> CREATE_ALWAYS,
>> FILE_ATTRIBUTE_TEMPORARY|FILE_FLAG_SEQUENTIAL_SCAN,
>> NULL);
> Maybe FILE_FLAG_DELETE_ON_CLOSE flag will be usefull in
> this situation ? Let the OS delete temp file itself.
Thanks for your input.
I believe this was all explored a while back. Off hand, if I remember,
there was some complex file sharing conflicts and/or an OS difference. I
don't recall, but it was explored for sure. Our system is WIN32
compliant, meaning it is single sourced to work from Win95 and beyond.
hmmmmmmm, this does raise a reason question to explore.
This is part our CGI system for our Web server. Customer defines the
CGI script engine (server side EXE) that will be spawn based on a CGI
URL file extension.
Extension: *.PHP
Engine: c:\php\php-cgi.exe
Extension: *.PL
Engine: c:\perl\perl.exe
The file handle is part of the standard I/O and "piping logic" for the
sub-process. (Note: Not a real pipe).
I wonder if the customer's script engine did not let go of the handle
when it was finished, thus preventing the deletion of the file when the
subprocess finished and the parent thread destructor, closed the handle
and deleting the file.
That sounds likes it waste of time to check but who knows :-)
Hector Santos
>> But we are deleting the file in our destructor class.
>
> But why does the customer had over 65K tmp-files?
Good question. This week long investigation ended this morning when he
posted his final finding to solve the problem. This is all he had to
say:
----- Original Message -----
From: <ROLF XXXXX>
To: <WINSERVER SUPPORT>
Newsgroups: winserver.public.gamma.testing
Sent: Saturday, February 04, 2006 6:29 AM
Subject: Re: CGI not working - problem solved
Unbelievable, I hate Windows ;)
After replacing wchttps.dll [our web server] without luck I tried
it on another server and the CGI worked with the gamma AUP. Then I
reinstalled Perl again on the real server but the CGI didn't work.
After this I logged on as administrator and the CGI worked... then
I played with user access rights for the normal user account but the CGI
didn't work.
The real problem here: the user temporary folder was full of
cgi*.tmp files (over 65000 files). Deleted all these files and
the CGI are working...
Thanks for your help, Hector. Because you didn't have a problem
it must have been something on my end.
Rolf
---------------
He basically thought it was first related to our GAMMA version thats
been in field-testing for over 2-3 months. When I asked him to replace
the DLL from the last stable releases, he posted the above. My last
reply was to ask the same question:
"Glad you found it .... why 65K files? ... Are you having
system reboot or CGI GPF abort problems?"
No response yet.
> Also the flag (FILE_FLAG_DELETE_ON_CLOSE) which Scherbian already
> pointed out might be interesting.
Right, this was explored in the past, but the current logic is pretty
solid. No need to change what works. :-) Now this came up. I might
have to revisit it.
> Of course, today, there might also be problems with apps that
> hook API functions...
You got that right. :-) These days, it leaves you with all sort of
"uneasy" sqeazy feelings with all the background stuff going on.
Thanks
---
Hector