fork/exec & close file descriptors

[alister]

On Wed, 03 Jun 2015 22:07:47 +1000, Steven D'Aprano wrote:

> On Wed, 3 Jun 2015 07:38 pm, alister wrote:
> 
>> On Wed, 03 Jun 2015 10:41:44 +0300, Marko Rauhamaa wrote:
> [...]
>>> Here's the deal: the child process is saddled with file descriptors it
>>> never wanted in the first place. It can't decline them. Now you're
>>> saying it can't even dispose of them.
>>> 
>> No You cab dispose of them you just need to warn the user that the
>> action did not complete correctly & there may be errors with the data.
> 
> *What* action? Pay closer attention to what Marko wrote:
> 
> "the child process ..."
> 
> How does the child process know what action didn't complete? What error
> message are you going to display to the user?
> 
> "Error when closing file descriptor 123456"
> 
> What action do you think the user can take on seeing this error message?
> 
> 
>> Example What does your test editor do if you try to save a file back to
>> a USB stick that has been removed? does it simply let you think the
>> file has been successfully saved? i hope not.
> 
> 
> Correct me if I'm wrong, but don't you get an error when you try to
> *open* a file on a missing USB stick?
> 
> There are at least three opportunities to get an error when writing a
> file:
> 
> * opening the file;
> * writing to the file;
> * closing the file.
> 
> It's not clear what conditions will lead to the first two succeeding but
> the third failing, or what to do if you get such an error. If you don't
> know what caused close() to fail,

open file for appending data
write some data
remove mem stick
now try to close file

> then you can't do anything about it,
Correct you cant do anything about it.
> and if you can't do anything about it, what's the point in reporting the
> error to the user who will just get frustrated and nervous and not be
> able to do anything about it either?

Because they need to know they may have just lost important data whilst 
they still have a chance to do it again. finding out 6 months later that 
they had screwed up saving data on a multi-million pound account will not 
be good & quite rightly considered to be due to a bug in your software.


> 
> I'm sure that there are circumstances where an error when closing a file
> is a clear and obvious fault that should be reported. But in the
> scenario that Marko is describing, I'm not so sure that is the case.

from the scenario Marco is reporting I get the impression that he is 
having to interact with a system that is fundamentally flawed from the 
ground up.



-- 
Standards are crucial.  And the best thing about standards is: there are
so ____many to choose from!