delete will assure file is deleted?

[Jeremy Bowers]

On Tue, 26 Apr 2005 21:24:30 +0200, andreas wrote:

> On Tue, Apr 26, 2005 at 03:13:20PM -0400, Jeremy Bowers wrote:
>> On Tue, 26 Apr 2005 03:40:16 -0700, ajikoe at gmail.com wrote:
>> 
>> > Hello Mike,
>> > I have to know this topic otherwise my program has to check whether the
>> > file / files are already deleted and this is a little bit messy.
>> 
>> I would be fairly confident in asserting that assuming the file is there,
>> you have permissions, etc., basically that the call succeeds, that the
>> file will be gone.
> Not exactly. The system call is called remove not by accident. It's not
> called delete. So for example if you have a file with multiple names (so called
> hard links) the file will not be gone after os.remove('file')

This gets into another distinction that I didn't want to get into, given
that my message was heavy enough as it is.

But I would say, that even if "file_a" and "file_b" are both (hard) linked
to the same file, and I "remove" "file_a", I am perfectly justified in
saying that "file_a" is gone, deleted, removed, what have you. The file,
the thing we called "file_a", is no longer accessible. That some operating
systems separate "file" from "contents" and thus that I can get at the
contents in some other way doesn't really make that statement untrue;
"file_a" is still gone. "file deleted" hasn't meant "file contents
eliminated from the disk entirely", well, as far as I know, *ever*;
certainly there were undelete operations in DOS, and that's as far back as
I can attest to personally, but I know that "undelete"s could be done
before then, too. In fact one must search in computing for anything to
ever truly be *eliminated*; in more than just file systems, we
de-allocate, re-allocate for something else, and just overwrite. That's a
pervasive pattern.