From murdoch.duncan at gmail.com  Mon Jul 10 13:13:13 2017
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Mon, 10 Jul 2017 07:13:13 -0400
Subject: [Rd] [New Patch] Fix disk corruption when writing
In-Reply-To: <1631c430-ce0a-ff60-6b22-cdacfc1a80b6@insa-toulouse.fr>
References: <CAPXDfF=770SgtaLoMeaF7XGUfj3wFSU6hUn6ZFrds0VnwG_+zA@mail.gmail.com>
 <ba1bb252-8524-ce6d-b0d7-0d66a09789d2@gmail.com>
 <CA+A1kV5xB3yfD2SnKenrnrfgV6wDObQW8vFMxUVQd2kxTc0BjQ@mail.gmail.com>
 <1093380f-a632-ce28-af21-a87e1a40a8db@gmail.com>
 <8ede4416-7745-e66c-7d2f-53c04f1a9067@insa-toulouse.fr>
 <fe2b1e03-2f57-820e-6226-217be4184907@insa-toulouse.fr>
 <0783f593-8624-6f3f-7c54-eb3ab2938a48@insa-toulouse.fr>
 <42077a0f-0e88-8400-8310-afaaa5ef6f9e@gmail.com>
 <ed2899b8-f945-1dad-348a-cee0f8614ba7@insa-toulouse.fr>
 <e8804ff7-473f-3b89-fa65-c1b0d79d85e3@gmail.com>
 <e1cf1c31-2e7c-72cb-453f-68df8321cc3f@insa-toulouse.fr>
 <8ca82104-19ae-a7be-d27f-9f2982b63140@gmail.com>
 <ce8dbd19-c6f1-fcf0-c9af-fccc27eb37c8@insa-toulouse.fr>
 <02239f51-3592-d3f3-5f4a-f479b35b4da9@gmail.com>
 <a5920916-a708-14d3-0e0f-66e5f35f7871@gmail.com>
 <ce5bb61d-0eb4-cc7d-49ec-d43b8de14eab@insa-toulouse.fr>
 <a974c35e-aadb-c9b7-af70-f486e3c24dd2@gmail.com>
 <1631c430-ce0a-ff60-6b22-cdacfc1a80b6@insa-toulouse.fr>
Message-ID: <49f943c9-2e1f-65a5-dcd9-62e9773e57c0@gmail.com>

On 10/07/2017 5:34 AM, Serguei Sokol wrote:
> Le 10/07/2017 ? 11:19, Duncan Murdoch a ?crit :
>> On 10/07/2017 4:54 AM, Serguei Sokol wrote:
>>> Le 08/07/2017 ? 00:54, Duncan Murdoch a ?crit :
>>>> I have now committed changes to R-devel (rev 72898) that seem to catch large and small errors.  They only give a warning if the error happens when the
>>>> connection is closed, because that can happen asynchronously
>>> For this asynchronous behavior, would not it be more useful to have
>>> the name of the file that failed at closing? If many files were open
>>> during a session and not closed explicitly (yes, bad practice but it
>>> can happen), the warning message doesn't help to understand
>>> which of files were corrupted, e.g.:
>>>  > fc=file("/dev/full", "w")
>>>  > write.csv("a", file=fc)
>>>  > q("yes")
>>> Warning message:
>>> In close.connection(getConnection(set[i])) :
>>>    Problem closing connection:  No space left on device
>>>
>>> Having only "set[i]" for indication is not very informative, is it?
>>
>> To debug your failure to close fc, reproduce the conditions before the warning was issued, and call showConnections().
> It can help in some cases but in all.
> First, to reproduce the exact condition of failure is not always possible. It could
> happen after a long calculation and the environment that caused
> the failure could evolve meantime. And second, having the list of
> connections still does not say which one (or many) has/have failed as
> we have only "set[i]" not even the connection number (which in turn
> could be not the same between the first failure and a tentative to reproduce it).
>
> Is adding con->description to the warning message problematic in any sens ?

Yes, we don't know if it is still valid after the connection has been 
closed.  It's just a pointer, whose target is allocated when the 
connection is created, and deallocated when it is closed.  Using it 
after closing could lead to a seg fault.

Duncan



[Rd] [New Patch] Fix disk corruption when writing
Duncan Murdoch