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, [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list