On 6/26/06, Tim Jenness <t.jenness@jach.hawaii.edu> wrote: > 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). This is on my TODO list. So long as nobody gets to it first anyway. :-) Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"