Re: Linking to open file descriptor

=item new_tmpfile

Creates an C<IO::File> opened for read/write on a newly created tempor
+ary
file.  On systems where this is possible, the temporary file is anonym
+ous
(i.e. it is unlinked after creation, but held open).  If the temporary
file cannot be created or opened, the C<IO::File> object is destroyed.
Otherwise, it is returned to the caller.

=back
[download]

As the temp_file has been unlinked you will be out of luck. Even if it was not all you could do would be to effectively rename it within its current dir. If you move it you are doing the IO anyway. Just copy it to whatever file wherever you want seems pretty logical to me.....

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Comment on Re: Linking to open file descriptor Download Code

Replies are listed 'Best First'.
Re: Re: Linking to open file descriptor by shotgunefx (Parson) on Nov 07, 2002 at 21:57 UTC
"Even if it was not all you could do would be to effectively rename it within its current dir." This would be acceptable. What I'm looking to do more or less is keep the temp file between sessioned runs. If the file is "kept" "processed" whatever, then it would get copied somewhere, if not destroyed at the end of session. The files are potentially large which is why I would like to avoid the copy. It's potentially many session running at once as well. I could just copy the parent module, change the name and hack it to use named temp files but then there's maintainence problems, etc everything there's a new release. It just seems wasteful to copy what I already have in this particular case. -Lee "To be civilized is to deny one's nature."	[reply]
Re: Re: Re: Linking to open file descriptor by tachyon (Chancellor) on Nov 08, 2002 at 10:25 UTC
If the module is OO why not just over-ride the new_tempfile method. If it is not possible in the current release (because there is not a new_tempfile method) then write a patch and supply it to the author so it will appear in future releases.....thus avioding the maintenance problem. Given the relative speed issues I would still think copy will be acceptable with negligible performance hit. After all native bus and disk IO speed is orders of magnitude faster than the file upload per se. cheers tachyon s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print	[reply]