[DUG] Delete (File) Function ?

[Myles Penlington]

Beware of how you copy/duplicate handles, if you do, as every
copy/duplicate of the file handle must be closed. 

And some windows functions return you file handles or duplicates which
you must then close - has caught us out more than once.

 

Of course once the program exits, the windows OS is supposed to clean up
after you, if you leave any handles open.

As a rough guide I use process explorer and see if over time our handle
counts rise, and in conjunction with breakpoints on close down/terminate
ensure that the handle count decreases as expected. Of course a resource
profiler will give you the same info e.g. the automated QA software.

 

Myles.

 

From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz]
On Behalf Of John Bird
Sent: Monday, 30 June 2008 3:04 p.m.
To: 'NZ Borland Developers Group - Delphi List'
Subject: Re: [DUG] Delete (File) Function ?

 

These zip files that get deleted are on a server, so it is not rebooted
often enough to fix the not-deleted files this way.  The best approach I
found was to check the return value of the DeleteFile function, and if
it was not true (successful) then retry it again next time a cleanup was
due until successful.   That seems to have worked, even though I am
still in the dark why it ever might have failed in the first place.

 

With the files left open - the application most defintely does exit and
close files properly (from its side) even if the server leaves them in
use. Some parts of it are legacy (DOS) programs but the log files always
confirm it executed its close and finish code in each case.

 

 

	Not really going to get into the specifics of what's happening
in your particular instances, but another suggestion might be to make
use of the RunOnce key in the Registry to delete files the next time
Windows starts up.

	 

	See http://delphi.about.com/cs/adptips1999/a/bltip0799_3.htm for
some sample code.

	 

	However, IMHO Windows itself doesn't keep files open any longer
than requested (maybe unless they're DLLs or something).  If the file in
question is a file opened/used by your application, and Windows tells
you it's in use, then I'd strongly suggest your app hasn't closed and
released the file handle properly.

	 

	Cheers,

	 

	C.

	 

	
________________________________


	From: delphi-bounces at delphi.org.nz
[mailto:delphi-bounces at delphi.org.nz] On Behalf Of John Bird
	Sent: Monday, 30 June 2008 1:37 p.m.
	To: 'NZ Borland Developers Group - Delphi List'
	Subject: Re: [DUG] Delete (File) Function ?

	I have come across similar problems on Windows Servers over the
years in a couple of cases:

	 

	1 - Data Files (non-database in this case)  that have been
updated and finished with and closed may remain open or in use as far as
the Server goes.   Sometimes this times out after a few minutes and the
file does become not in use.  Sometimes it has to be closed manually on
the server (Control panel/Administrative tools/Shared files/Open Files
allows one to manually browse and close an open connection).

	 

	Sometimes even more puzzling is a file remaining with a locked
block (a file open for shared read/write) long after the updates have
finished.  Same solution.

	 

	Incidentally I discovered There is a useful Windows command line
variant of the Administrative Tools GUI - 

	 

	OPENFILES /Disconnect /O Read/Write (+ other options)

	but  haven't yet have had a chance to find out if that only
deals with files opened from this workstation or for any workstation or
whether it can be used from a workstation to close files on the server.

	 

	2 - Zip file archives that get deleted after a time (usually
weeks after created) sometimes fail to delete - using the same
DeleteFile call as you used.  I have not figured out yet why these fail
to delete, but they are on a Windows server again.

	 

	I am most interested to hear anyone shed light on this!

	John



Attention:
This communication is confidential and may be legally privileged.  If you are not the intended recipient, please do not use, disclose, copy or distribute it, other than to return it to us with your confirmation that it has been deleted from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20080630/312cc1a2/attachment.html