At 12:10 PM -0400 9/12/03, [EMAIL PROTECTED] wrote:
>I had noted in the past that temporary files were starting to pile up in
>my SYS$SCRATCH: directory after runs of "mmk test" in a
>perl source tree. Unfortunately I have bad news: it appears
>that basic perl use with recent maint kits will lead to accumulation
>of these temporary files. I
The problem originates in PerlIO_tmpfile in perlio.c, which creates
temporary files but does not seem to do anything to clean them up.
It calls mkstemp() and fdopen() to create temporary files, but there
is nothing that would set fop=dlt to cause the file to be deleted on
close. One thing I don't know offhand, though, is whether PerlIO
ever needs to close a temporary file and reopen it, or whether it
always keeps it open until it's completely done with it. If the
latter, then it should be safe to delete on close.
Win32 goes its own way in perlio.c and I suppose we could too. Quite
possibly the following would be all that would be required, because
if I read the headers right it would cause us to end up using the
Perl_my_tmpfile() from vms.c, which does set fop=dlt.
--- perlio.c;-1 Sat Aug 30 15:12:10 2003
+++ perlio.c Fri Sep 12 11:57:51 2003
@@ -4861,7 +4861,7 @@
if (fd >= 0)
f = PerlIO_fdopen(fd, "w+b");
#else /* WIN32 */
-# ifdef HAS_MKSTEMP
+# if defined(HAS_MKSTEMP) && ! defined(VMS)
SV *sv = newSVpv("/tmp/PerlIO_XXXXXX", 0);
/*
[end of not yet a patch]
I have not had a chance to build with this, much less test, but
that's what I know about the situation. The workaround is obviously
to clean out your scratch space frequently.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
