在C中使用tmpfile()时的临时文件位置

roo*_*kea 5 c linux posix glibc temporary-files

$ man tmpfile

该标准未指定tmpfile()将使用的目录.Glibc将尝试定义的路径前缀P_tmpdir <stdio.h>,如果那个目录/ tmp失败.

我使用的是Ubuntu 13.10 x86_64,gcc和libc BTW.

所以当我尝试使用tmpfile()创建临时文件时,我在/ tmp中看不到任何临时文件.(我可以# define P_tmpdir "/tmp"在stdio.h中看到).这是我使用的代码片段:

#include <stdio.h>

int main(int argc, char **argv)
{
    FILE *tmp;

    tmp = tmpfile();                            // Where's this file?
    scanf("%*d");

    return 0;
}
Run Code Online (Sandbox Code Playgroud)

$ ./tmpfile
现在,当scanf正在等待下一个(冗余)输入时,我应该能够在/ tmp中看到一个临时文件.但我不能.那么这个tmpfile到底在哪里创建?

Jen*_*edt 7

可能直接删除目录中的文件条目.在POSIX系统上,只要您有一个打开的文件描述符,文件本身在删除后仍然有效.(在您的情况下隐藏在FILE*返回值中.)

使用这种技术,没有人可以潜入并打开该文件,只能通过您的变量访问它tmp.

  • @alk的答案表明确实是 (2认同)

alk*_*alk 7

编译您的代码并运行它会strace显示文件的位置和名称:

$ ./a.out
execve("./main", ["./main"], [/* 31 vars */]) = 0
brk(0)                                  = 0xe0c000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f038c51a000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=103425, ...}) = 0
mmap(NULL, 103425, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f038c500000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\357\1\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1603600, ...}) = 0
mmap(NULL, 3717176, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f038bf71000
mprotect(0x7f038c0f3000, 2097152, PROT_NONE) = 0
mmap(0x7f038c2f3000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x182000) = 0x7f038c2f3000
mmap(0x7f038c2f8000, 18488, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f038c2f8000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f038c4ff000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f038c4fe000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f038c4fd000
arch_prctl(ARCH_SET_FS, 0x7f038c4fe700) = 0
mprotect(0x7f038c2f3000, 16384, PROT_READ) = 0
mprotect(0x7f038c51c000, 4096, PROT_READ) = 0
munmap(0x7f038c500000, 103425)          = 0
stat("/tmp", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
getpid()                                = 25957
open("/tmp/tmpfflAlKG", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/tmp/tmpfflAlKG")               = 0
fcntl(3, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
brk(0)                                  = 0xe0c000
brk(0xe2d000)                           = 0xe2d000
fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f038c519000
lseek(3, 0, SEEK_CUR)                   = 0
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f038c518000
read(0, alk
"alk\n", 1024)                  = 4
exit_group(0)                           = ?
Run Code Online (Sandbox Code Playgroud)

"/tmp/tmpfflAlKG" 通过创建 open()

open("/tmp/tmpfflAlKG", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
Run Code Online (Sandbox Code Playgroud)

然后立即得到 unlink()

unlink("/tmp/tmpfflAlKG")               = 0
Run Code Online (Sandbox Code Playgroud)

所以可见的目录条目消失了。

由于仍然对进程开放,文件本身对进程保持有效,直到进程关闭close()它。后者通过调用隐式发生exit_group()

exit_group(0)                           = ?
Run Code Online (Sandbox Code Playgroud)

  • 请注意,较新的 glibc 版本将首先使用“O_TMPFILE”标志,这会在目录的文件系统中创建一个未命名的 inode,并且没有指向它的链接,并且只有在不起作用时才会回退到常规的“open”+“unlink”(例如因为文件系统不支持它)。 (2认同)