> If it's raising an error, then yes, at the moment, the caller does not > have the required permissions to delete the file. If you *do* have > permission to delete the file, even if it's read only, then you won't > get the error. I'm not sure what the conflict is here. > [...] > The error says, you don't have permission to do that. Which is a fact.
Both users and administrators understand permissions as a reference to ownership. Owning X gives you permissions to do with X as you please, including deleting it. Linux system errors are plagued with bad decisions and pathologically bad reporting. I would expect the same from MS Windows. There's no reason to ever consider them as good examples for anything besides, maybe, as a source for jokes. Good errors have these properties: 1. Present the problem as a logical inconsistency (the real reason why there's an error is because you want both P and ~P). For example: file X assumed to both exist and to not exist (instead of the typical, but bad "file not found"). 2. Supply enough information to locate the reason for the error. For example, when a file should both exist and be missing, the full normalized path to the file should be presented with the error. 3. Recommend a possible strategy to mitigate the error (either create the missing file or remove the existing file, following the previous examples). 4. On-demand provide steps leading up to the error (i.e. stack-trace, previous errors causing the current error to be raised). 5. Be as specific as possible. Don't leave cliff-hangers and vague directions to search the logs for better messages etc. In light of the above, informing users that they don't have permissions to delete a file while the reason they can't delete it is the file *mode* rather than *ownership* is unhelpful. Users don't expect file mode to affect permissions. The reason the error is reported in this way by the system is, in most likelihood, the developer taking a shortcut somewhere. Reusing some structure or an exit code etc. Also, it's not uncommon for developers to not understand themselves the behavior model they've created for their program and to instead rely on their knowledge of the implementation details to justify the counterintuitive behavior. Bottom line: I think that having a FileReadOnly exception is a good idea because it more precisely reports the problem and gives users a direction for fixing it, whereas reporting permissions error doesn't. -- https://mail.python.org/mailman3//lists/python-list.python.org
