Is the remove function guaranteed to delete the file?

Question

The wording of the C99 standard seems a bit ambiguous regarding the behavior of the remove function.

In section 7.19.4.1 paragraph 2:

The remove function causes the file whose name is the string pointed to by filename to be no longer accessible by that name. A subsequent attempt to open that file using that name will fail, unless it is created anew.

Does the C99 standard guarantee that the remove function will delete the file on the filesystem, or could an implementation simply ignore the file -- leaving the file on filesystem, but just inaccessible to the current program via that filename-- for the remainder of the program?

Answer 1

I don't think you're guaranteed anything by the C standard, which says (N1570, 7.21.4.1 2):

The remove function causes the file whose name is the string pointed to by filename to be no longer accessible by that name. A subsequent attempt to open that file using that name will fail, unless it is created anew. If the file is open, the behavior of the remove function is implementation-defined.

So, if you had a pathological implementation, it could be interpreted, I suppose, to mean that calling remove() merely has the effect of making the file invisible to this running instance of this program, but that would be, as I said, pathological.

However, all is not utterly stupid! The POSIX specification for remove() says,

If path does not name a directory, remove(path) shall be equivalent to unlink(path).

If path names a directory, remove(path) shall be equivalent to rmdir(path).

And the POSIX documentation for unlink() is pretty clear:

The unlink() function shall remove a link to a file.

Therefore, unless your implementation (a) Does not conform to POSIX requirements, and (b) is extremely pathological, you can be assured that the remove() function will actually try to delete the file, and will return 0 only if the file is actually deleted.

Of course, on most filesystems currently in use, filenames are decoupled from the actual files, so if you've got five links to an inode, that file's going to keep existing until you delete all five of them.

_References:

_{The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition
The Open Group Base Specifications Issue 7, IEEE Std 1003.1™, 2013 Edition
Note:"IEEE Std 1003.1 2004 Edition" is "IEEE Std 1003.1-2001 with corrigenda incorporated". "IEEE Std 1003.1 2013 Edition" is "IEEE Std 1003.1-2008 with corrigendum incorporated".}

Answer 2

The C99 standard does not guarantee anything.

The file could remain there for any of the reasons unlink(2) can fail. For example you don't have permission to do this.

Consult http://linux.die.net/man/2/unlink for examples what can all go wrong.

Answer 3

On Unix / Linux, there are several reasons for the file not to be removed:

1. You dont't have write permission on the file's directory (in that case, remove() will return ERROR, of course)
2. there is another hard link on the file. Then the file will remain on disk but only be accessible by the other path name(s)
3. the file is kept open by any process. In that case the directory entry is removed immediatly, so that no subsequent open() can access the file (or an appropriate call will create a new file), but the file itself will remain on disk as long as any process keeps it open.

Answer 4

Typically, that only unlinks the file from the file system. This means all the data that was in the file, is still there. Given enough experience or time, someone would be able to get that data back.

There are some options to not have the file be read again, ever. The *nix utility shred will do that. If you are looking to do it from within a program, open the file to write, and write nonsense data over what you are looking to 'remove'.