On Sun, 24 Jul 2005 01:12, James Bunton wrote:
> Data does change after you register, every time your MSN contact
> changes.
> If the disk was running out of space then an exception should be
> generated.
> Are there any exceptions in the log that correspond to these blank
> files?
I can't find anything suspicious in the day that the problem occurred. But
when I think about it, if it really were a disk space problem, there wouldn't
have been enough space to even write the log files.
TX
--
Email: Trejkaz Xaoza <[EMAIL PROTECTED]>
Web site: http://trypticon.org/
Jabber ID: [EMAIL PROTECTED]
GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F A62C B8C7 BC8B 037E EA73
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://modevia.com/pipermail/py-transports/attachments/20050724/5b08f919/attachment.pgp
From [EMAIL PROTECTED] Sun Jul 24 01:26:20 2005
From: [EMAIL PROTECTED] (James Bunton)
Date: Sun Jul 24 01:26:31 2005
Subject: [py-transports] Re: Registration hanging issues / empty file
problem
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
On 24/07/2005, at 10:59 AM, Trejkaz wrote:
> On Sun, 24 Jul 2005 01:12, James Bunton wrote:
>> Data does change after you register, every time your MSN contact
>> changes.
>> If the disk was running out of space then an exception should be
>> generated.
>> Are there any exceptions in the log that correspond to these blank
>> files?
>
> I can't find anything suspicious in the day that the problem occurred.
> But
> when I think about it, if it really were a disk space problem, there
> wouldn't
> have been enough space to even write the log files.
That's true :)
You're aware that removing the transport from your list, or sending a
presence unsubscribe will cause it to delete your spool file?
Just so you know, the write code goes like this.
# text is the entire contents of the new file, generated in memory
already
f = open(self.name + "/" + file + ".xml", "w")
f.write(text)
f.close()
At line one the file is blank, at line 2 its written again, and at line
3 it should be flushed to disk.
I don't see how line 1 could succeed and then line 2 fail.
This is the only routine that writes to these files btw.
You're not running two instances of the transport with the same spool
dir are you? That might do it.
---
James
