Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I found that if I transfer a great amount of data between two processes via pipe, some temporary file will be created by linux in /tmp directory. If the pipe operation succeeds, the corresponding temporary file will be removed by OS automatically. But if the operation failed, the tmp file remains there.

For some reason, I don't want the user have the oppotunity to get the data I transfered trhough pipe, so I don't want anything left on harddisk even if my program crashed. How can I do this?

share|improve this question
3  
I'm very doubtful that it is the OS creating these files, particularly, I doubt it is the pipe operation. –  nb2580 Dec 9 '09 at 10:42
    
@Neil: Very good point. @OP: Are you sure the receiver isn't caching the data it receives on stdin to the tmp file? If it's not your own code and not open source, you can probably check by redirecting your output from your sender to a file, and then sending that into the receiver process as its input stream, e.g.: sender > filename then receiver < filename. I'd check for the tmp file during both ops, to see if either the sender or receiver is doing it. –  T.J. Crowder Dec 9 '09 at 10:47
2  
Not an answer, but I found a lot of useful information on pipe handling here: <slacy.com/blog/2008/12/on-mkfifo-and-doing-the-impossible/>; . Don't know how authoritative this person is, but he specifically mentions that a mkfifo-created pipe never does any buffering (at all!) and never creates files. –  Carl Smotricz Dec 9 '09 at 13:39
1  
@Carl Smotricz: Link is broken, so here: slacy.com/blog/2008/12/on-mkfifo-and-doing-the-impossible –  nalply Dec 9 '09 at 14:29
    
Also, writing to a pipe will block if the pipe is too full (until someone reads from the other end). –  Jason Orendorff Dec 10 '09 at 18:19
add comment

migrated from stackoverflow.com Dec 11 '09 at 1:34

This question came from our site for professional and enthusiast programmers.

3 Answers

up vote 8 down vote accepted
  1. pipes don't store data on disk. /bin/echo foo | grep bar doesn't create any files. try strace -f sh -c '/bin/echo foo | grep bar' to see all the system calls made by a shell when running a pipeline. echo is a shell builtin, so I suggested /bin/echo to make the shell run an executable.

  2. /tmp doesn't have to be on disk. It can be mounted on tmpfs (i.e. backed by virtual memory). Note that a reboot will empty /tmp in that case, so use /var/tmp for anything you want to leave around.

If what you're doing is putting data into a file, then it's not using a pipe. If the file is a fifo, not a regular file, then it's just a named rendezvous, and doesn't contain data. Use ls -l to find out.

And note that if you're hoping to stop users from seeing what's going through pipes in processes they own, you are pretty much SOL, because strace can inspect everything a process does that interacts with anything outside the process, except for reading/writing mmapped shared memory. ltrace is even more invasive. If your program will run on systems where the local user has root, you can't stop them at all. On Unix, root can do anything, and has powerful tools for the purpose.

share|improve this answer
add comment

Dirty hack: Encrypt the data before sending and decrypt it on receiving if you can change both of the processes ...

share|improve this answer
    
Wouldn't call it a dirty hack, actually: If the data is sensitive, seems an appropriate solution. But I'm curious about the tmp file. Is the OP right that the kernel is creating it? Or is Neil right and it's one end of the pipe or the other... –  T.J. Crowder Dec 9 '09 at 10:44
    
The kernel is not creating a temporary file. On the other hand, it's very likely that the receiving process is creating a temporary file. This is pretty common, since if you want to seek in your input you need to write it to a file first. –  larsks Dec 11 '09 at 2:55
add comment

A true pipe is a block of memory in the kernel, a buffer that is read/written by some processes. It does not create files anywhere.

Some apps have options that switch between using pipes (faster, no hitting disk, takes a little more memory) and using temp files (takes a bit less memory, allows you to possibly see the temp files, a touch slower). gcc is one such application, though probably are others.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.