Follow

Keep Up to Date with the Most Important News

By pressing the Subscribe button, you confirm that you have read and are agreeing to our Privacy Policy and Terms of Use
Contact

Is it possible to read a short-lived file reliably in /tmp due to periodic cleanup?

I’m considering making my application create a file in /tmp. All I’m doing is making a temporary file that I’ll copy to a new location. On a good day this looks like:

  1. Write the temp file
  2. Move the temp file to a new location

However on my system (RHEL 7) there is a file at /usr/lib/tmpfiles.d/tmp.conf which indicates that /tmp gets cleaned up every 10 days. From what I can tell this is the default installation. So, what I’m concerned about is that I have the following situation:

  1. Write the temp file
  2. /tmp gets cleaned up
  3. Move the temp file to a new location (explodes)

Is my concern founded? If so, how is this problem solved in sophisticated programs? If there are no sophisticated tricks, then it’s a bit puzzling to me as I don’t have a concrete picture of what the utility of /tmp is if it can be blown away completely at any moment.

MEDevel.com: Open-source for Healthcare and Education

Collecting and validating open-source software for healthcare, education, enterprise, development, medical imaging, medical records, and digital pathology.

Visit Medevel

>Solution :

this should not be a problem if you keep a file descriptor open during your operation. As long as a file descriptor is open, the FS keeps the file on disk but it just don’t appear when using ls. So If you create another name for this file, it will "resurect" in some way. Keeping an open fd on a file that is deleted is a common way to create temporary files on linux

see the man 3 unlink:

The unlink() function shall remove a link to a file. [..] unlink() shall remove the link named by the pathname pointed to by
path and shall decrement the link count of the file
referenced by the link.

When the file’s link count becomes 0 and no process has the file open, the space occupied by the file shall be freed and the file
shall no longer be accessible. If one or more
processes have the file open when the last link is removed, the link shall be removed before unlink() returns, but the removal of
the file contents shall be postponed until all
references to the file are closed.

Add a comment

Leave a Reply

Keep Up to Date with the Most Important News

By pressing the Subscribe button, you confirm that you have read and are agreeing to our Privacy Policy and Terms of Use

Discover more from Dev solutions

Subscribe now to keep reading and get access to the full archive.

Continue reading