Re^3: Is there a way to open a memory file with binmode :raw? (open undef)

Yeah, but that way of creating temporary files doesn't even honor $ENV{TMPDIR} (at least in some configurations), which makes it one of the worst ways to make temporary files in Perl in my book. I was rather shocked when I discovered such in the Perl source code (trying to figure out why Plack temporary files were being put into the wrong directory).

- tye

Comment on Re^3: Is there a way to open a memory file with binmode :raw? (open undef)

Replies are listed 'Best First'.
Re^4: Is there a way to open a memory file with binmode :raw? (open undef) by shmem (Chancellor) on Oct 13, 2015 at 07:35 UTC
trying to figure out why Plack temporary files were being put into the wrong directory On recent linux system you can find out the original location of the deleted file by examining /proc: `qwurx [shmem] ~> perl open $fh, "+>", undef or die "Can't create anonymous storage: $!"; $file = "/proc/$$/fd/" . fileno $fh; print "$file => ", readlink( $file ), $/; __END__ /proc/26628/fd/3 => /tmp/PerlIO_eVAtFg (deleted)` [download] On systems which lack /proc/$$/fd it can be quite annoying to find out, specially when the file system is full and a process is just sitting around in IOWAIT. In this condition there's a difference between disk usage of device and file system. Found that on an old Solaris server running a program which employed this trick: create file, get handle, unlink. Took me some time to find out. perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'	[reply] [d/l]
Re^5: Is there a way to open a memory file with binmode :raw? (lsof) by tye (Sage) on Oct 13, 2015 at 16:58 UTC
`sudo lsof -p $PID` is what I usually use. Even more likely: `sudo lsof -p $PID \| grep -vw mem` [download] as I usually don't care about the rather large list of shared libraries that the process has open. Also: `sudo lsof /tmp \| grep deleted` [download] But, yes, lacking /proc makes the job harder for lsof. I haven't worked in such an environment recently, but I seem to recall lsof being able to report paths of deleted files that are still open on systems that didn't have /proc. Update: But note that the question that you quoted, "trying to figure out why Plack temporary files were being put into the wrong directory", is not answered by either of these approaches. These can answer "Where is Plack putting temporary files?". I already had the answer to that because I was asking "why". - tye	[reply] [d/l] [select]