Boost logo

Boost :

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.
>>>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 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at