|
From: Michael F. <fuz...@vo...> - 2011-11-18 11:23:20
|
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 |