RE: [boost] Review Request: Filesystem Library

From: Yitzhak Sapir (yitzhaks_at_[hidden])
Date: 2002-08-05 10:43:51

> -----Original Message-----
> From: James Dennett [mailto:jdennett_at_[hidden]]

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

I'm only writing this as a possible future user of "delete file" who uses mainly Windows-based platforms.  I don't have any special experience in deleting files that gives me additional insights.  Indeed, I'd not have thought of the difference between not accessible and not existing had it not been brought up, but once I started thinking about it, it seemed to me to be confusing several things together:
1) drive unmounts
2) postcondition
3) exception handling vs return values

In my opinion the main question that should be asked in each of these cases is how the program would normally want to handle the issue.
1) In case of drive unmounts (or path unmounts) it might want to stop what it were doing in case it was trying to delete several files in that path.  So an exception should be thrown that tells the program what is the longest part of the path that is still accessible, this way, knowing which files are a waste of time to try deleting or accessing.
2) postcondition: in most cases, users only care that the file no longer is accessible but the entire path is still mounted.  If they want to do anything in that case they might want to log, but even then (even in the case of passwords quoted above), they probably want to go ahead with what they intended to do (for example, deleting the encoded documents, so that even if a user outside has the passwords, they won't have both the passwords and the sensitive documents).
3) Based on (2), return true/false if the file was definitely deleted.  Throw an exception if the postcondition could not be fulfilled for any other reason (write protect, bad sector, path unmount, etc).  If a user wants to throw if the file was not definitely deleted but the postcondition holds, they can do so if they want.  It just seems to me to be the most infrequent case.