Front page | perl.perl5.porters |
Postings from June 2006
On Sun, 25 Jun 2006, Craig A. Berry wrote: > In article > <9b18b3110606251159xdb63ba5re71b316a91b7ea5a@mail.gmail.com>, > demerphq@gmail.com (demerphq) wrote: > >> If the semantics of 'open' where changed to support more advanced >> locking and sharing models, in memory temp files, or delete on close >> semantics then UNIX would just ignore or fake it as needed. But where >> the additional semantics are supported the os should do so. >> In fact i once recommended that open be extended to support the idea >> of opening a self deleting temporary file. On unix this would mean >> that open would do the unlink logic, on win32 it would do something >> else. Either way it would mean that programmers wouldnt have to worry >> about how it happens. > > Does the unlink_on_close feature of File::Temp not work on Win32? If > not, is it considered somehow difficult to make win32_tmpfile() > available from Perl so that File::Temp can do the Win32-appropriate > thing on Win32? Do programmers who use File::Temp "have to worry about > how it happens"? You could argue that File::Temp is not the > abstraction you would choose, but you can't argue that it doesn't > exist. I have no experience of programming on windows and I would love to receive a patch for File::Temp that finally sorts out this issue. Most of the complaints I receive about File::Temp come from people running out of temp files on windows because they have a very long running process that never cleans things up (the END block only runs at program exit). The OO interface to File::Temp helps a little but using the native API for Windows would be the best solution. Pod::Simple abandoned using File::Temp because of the Windows problem (and coded something up internally). -- Tim Jenness JAC software http://www.jach.hawaii.edu/~timj