From: James Dennett (jdennett_at_[hidden])
Date: 2002-08-03 09:59:02
David Abrahams wrote:
> From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
>
>
>>At Friday 2002/08/02 21:23, you wrote:
>
> ]> >
>
>>>Yes. Using the other function is dangerous. It provides a false sense of
>>>security by working in all testcases, then throws an exception in the
>>
> field
>
>>>when some other process gets in and deletes the file before we get a
>>>chance. Precondition checking should usually not be done with exceptions
>>
> in
>
>>>the first place, and I think this is a particularly bad use for it.
>>>[deleted]
>>>This example is much worse, since the problem will almost never show up
>>>during testing, and even if it did, there's absolutely no test you can
>>
> make
>
>>>to check whether the file will actually exist by the time you try to
>>
> delete
>
>>>it.
>>
>>It means that if the OS won't tell you whether it actually deleted the
>>file, the program won't know for sure.
>>You might not even be able to tell then (not all OS's report with
>>one-to-one correspondence with the truth).
>
>
> Please give two examples of a program that needs to delete a file and which
> cares not only that the file has been deleted, but that its own call to the
> OS was the one responsible for the deletion.
Wrong question? The issue is whether the file really
_has_ been deleted, or has just otherwise become
(possibly temporarily) inaccessible.
If I (via some program) was about to delete
a file "private_data/my_passwords" and failed because
somebody unmounted the relevant filesystem from under
me, I want to know -- the point of my delete request
was not that *I* don't want to be able to access the
file, but that I want the file gone, deleted, so that
others cannot access it.
The only way for a program to know that a file has really
been deleted, often, is for the OS to report success for
the delete operation.
This argues that it is right for a delete operation to
say whether it did the job, rather than just reporting
on the existence or otherwise of the file.