Re: [Configobj-develop] Safe File writing in ConfigObj

[Michael F. <fuz...@vo...>]

On 17 Nov 2011, at 09:00, Gibhardt, Holger wrote:

> Dear colleagues,
> 
> I am not sure, if this is the correct way to inform you from a specific
> problematic behaviour of this module:
> 
> Situation:
> 1. I make experiments with detectors and motors - with python as control
> software (on windows xp).
> 
> 2. I use configobj to log changes of status (movement of motors etc.). For
> years, all that works without problems.
> 
> 3. Since a couple of weeks, I use robocopy in parallel to copy new generated
> and changed files on a separate file server. This is done 47 times per day.
> 
> 4. It happens that if robocopy copies the changed .ini file and at the same
> time configobj wants to write new information into that file, that python
> hangs up. (This happened once a week and to some time to find out).

What do you mean by hangs up?

> 
> Solution:
> After hard work for finding the reason for the hang up, I came into the
> configobj module and found the following: If the handler is made at first,
> configobj uses safe methods for verifying the logfile. However, any attempt
> to write into the ini file is done unsafe:
> 
> def write:
> if outfile is not None:
>            outfile.write(output)
>        else:
>            h = open(self.filename, 'wb')
>            h.write(output)
>            h.close()
> 
> That means, file access is unsafe any time.


How does this make file access "unsafe"? (I don't know what you mean by unsafe here?)

> 
> Now, I derived a new class from configobj and added a new function, which
> only uses safe file access (with try blocks). And now, the problem is solved
> and I see, that this happens once a week - but the error is catched.


Can you show me the actual code? Do you just catch and ignore exceptions raised during writing? That sounds like a bad idea in general.

> 
> I think, it would be better to do this in the original configobj module, as
> the user takes it as whole and thinks, that it works well at any time. File
> access should be safe.

Well it should be, but errors mean that the file hasn't been written properly - so the correct thing to do is to just let the exception propagate I think. In your specific case it may be that retrying on exception is the right approach - but not for every case I don't think.

All the best,

Michael

> 
> However, thank you for this great module!
> 
> Holger
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
> 


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html