TMPFILE（）在Windows 7 64位系统 [英] tmpfile() on windows 7 x64

问题描述

在Windows 7上运行64位以下code

 的#include＆LT;＆stdio.h中GT;
＃包括LT＆;＆errno.h中GT;诠释主（）{
    INT I;
    FILE * tmp目录;
    对于（i = 0; I＆LT; 10000;我++）{
        错误号= 0;
        （！（TMP = TMPFILE（）））如果的printf（％失败D，ERR％d个\\ N，我，错误号）;
        FCLOSE（TMP）;
    }
    返回0;
}
 

给出错误号13（拒绝），对637和第一千零四通话，它工作正常在XP（没试过7 X86）。我缺少的东西，或这是一个错误吗？

解决方案

从手册页上的复习TMPFILE的位（），它返回一个 FILE * ：

<块引用>文件时，将自动被关闭或删除该程序将终止。

我对这个问题的结论是：。在删除Windows中的文件是怪异

当您删除Windows中的文件，只要东西持有手柄，你不能叫的CreateFile 上的东西用相同的绝对路径，否则会失败的NT错误code STATUS_DELETE_PENDING ，它被映射到Win32的code ERROR_ACCESS_DENIED 。这可能是其中 EPERM 在错误号的来源。你可以像Sysinternals的进程监视器的工具证实了这一点。

我的猜测是，不知何故CRT清盘创建具有的东西它之前所使用的相同名称的文件。我有时会看到，删除在Windows文件会出现异步，因为一些其他进程（有时甚至是防病毒产品，在反应的事实，你刚刚关闭删除-ON-接近手柄...）将离开手柄打开该文件，因此未来一段时间的窗口，你会看到一个可见的文件，你不能得到一个处理没有击中删除拒绝挂起/访问。或者，它可能是 TMPFILE 只是选择了一些其他进程正在一个文件名。

要避免这样的你可能要考虑的另一个机制的临时文件的事情...例如像Win32的 GetTempFileName 功能允许你创建你自己的preFIX这可能使冲突的可能性较小。这一功能似乎通过重试来解决竞争条件，如果创建失败，已经存在，所以要小心删除临时文件名，并事情产生 - 删除文件取消您的权利，与其他进程/线程同时使用它。

Running the following code on Windows 7 x64

#include <stdio.h>
#include <errno.h>

int main() {
    int i;
    FILE *tmp;
    for (i = 0; i < 10000; i++) {
        errno = 0;
        if(!(tmp = tmpfile())) printf("Fail %d, err %d\n", i, errno);
        fclose(tmp);
    }
    return 0;
}

Gives errno 13 (Permission denied), on the 637th and 1004th call, it works fine on XP (haven't tried 7 x86). Am I missing something or is this a bug?

解决方案

A bit of a refresher from the manpage of on tmpfile(), which returns a FILE*:

The file will be automatically deleted when it is closed or the program terminates.

My verdict for this issue: Deleting a file on Windows is weird.

When you delete a file on Windows, for as long as something holds a handle, you can't call CreateFile on something with the same absolute path, otherwise it will fail with the NT error code STATUS_DELETE_PENDING, which gets mapped to the Win32 code ERROR_ACCESS_DENIED. This is probably where EPERM in errno is coming from. You can confirm this with a tool like Sysinternals Process Monitor.

My guess is that CRT somehow wound up creating a file that has the same name as something it's used before. I've sometimes witnessed that deleting files on Windows can appear asynchronous because some other process (sometimes even an antivirus product, in reaction to the fact that you've just closed a delete-on-close handle...) will leave a handle open to the file, so for some timing window you will see a visible file that you can't get a handle to without hitting delete pending/access denied. Or, it could be that tmpfile has simply chosen a filename that some other process is working on.

To avoid this sort of thing you might want to consider another mechanism for temp files... For example a function like Win32 GetTempFileName allows you to create your own prefix which might make a collision less likely. That function appears to resolve race conditions by retrying if a create fails with "already exists", so be careful about deleting the temp filenames that thing generates - deleting the file cancels your rights to use it concurrently with other processes/threads.

这篇关于TMPFILE（）在Windows 7 64位系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！