C99标准的措辞似乎对remove函数的行为有点模糊。
在第7.19.4.1节第2段：
remove函数会导致文件名为filename指向的字符串不再以该名称访问。随后尝试使用名称将失败，除非重新创建。
C99标准是否保证remove函数将删除文件系统上的文件，或者实现是否可以简单地忽略文件-将文件留在文件系统上，但当前程序只能通过该文件名访问该文件-用于程序的其余部分？
我不认为C标准对你有任何保证，它说（N1570，7.21.4.1 2）：
remove函数会导致文件名为filename指向的字符串不再以该名称访问。随后尝试使用名称将失败，除非重新创建。如果文件是打开的，则删除的行为函数是由实现定义的。
因此，如果你有一个病态的实现，我想，它可以被解释为，调用remove()只会使文件对这个程序的运行实例不可见，但正如我所说，这将是病态的。
然而，这一切并不是完全愚蠢的！remove()的POSIX规范说，
如果路径没有命名目录，remove（path）应等同于unlink（path）。
如果路径命名一个目录，remove（path）应等同于rmdir（path）。
unlink()的POSIX文档非常清楚：
unlink（）函数将删除指向文件的链接。
因此，除非您的实现（a）不符合POSIX要求，并且（b）非常病态，否则您可以放心，remove()函数将实际尝试删除该文件，并且只有在实际删除该文件时才会返回0。
当然，在目前使用的大多数文件系统上，文件名与实际文件是解耦的，所以如果你有五个指向inode的链接，那么该文件将一直存在，直到你删除了所有五个链接。
参考文献：
Open Group Base Specification Issue 6，IEEE Std 1003.1，2004 Edition
开放式分组基础规范第7期，IEEE Std 1003.1™,2013版
注意："IEEE Std 1003.1 2004版"；是"；IEEE Std 1003.1-2001，包含勘误表"IEEE Std 1003.1 2013版"；是"；IEEE Std 1003.1-2008及其包含的更正"；。
C99标准不保证任何东西。
由于unlink(2)可能失败的任何原因，文件都可能保留在那里。例如，您没有这样做的权限。
咨询http://linux.die.net/man/2/unlink例如，什么都可能出错。
在Unix/Linux上，不删除文件有几个原因：
- 您没有对文件目录的写入权限（在这种情况下，
remove()当然会返回ERROR） - 文件上还有另一个硬链接。然后该文件将保留在磁盘上，但只能由其他路径名访问
- 该文件由任何进程保持打开状态。在这种情况下，目录条目会立即删除，这样后续的
open()就无法访问该文件（或者适当的调用会创建一个新文件），但只要任何进程保持打开，文件本身就会保留在磁盘上
通常，这只会取消文件与文件系统的链接。这意味着文件中的所有数据仍然存在。只要有足够的经验或时间，就有人能够取回这些数据。
有一些选项可以使文件不再被读取。*nix实用程序碎片可以做到这一点。如果你想在程序中执行，打开要写入的文件，并在你想"删除"的内容上写入无意义的数据。