[pskmail] Re: More tests - client to server only this time
- From: John Douyere <vk2eta@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Wed, 22 Dec 2010 17:48:06 +1100
Hi Rein and Per,
More information on the previous tests (today's email):
I tested the mail download with the client under Ubuntu (andLinux) instead
of Windows and got similar results except that this time there was not even
a zero size attachment. The attachment just disappeared although I could see
the decoded text in the terminal window was complete and accurate.
The email accounts were gmail to gmail.
Hope this helps,
73's John (VK2ETA)
On Wed, Dec 22, 2010 at 1:56 PM, John Douyere <vk2eta@xxxxxxxxx> wrote:
> Conditions:
>
> Server 1.0.26 running under andLinux (Ubuntu)
>
> Client is latest alpha revision 948 from svn running under WinXP SP3.
>
> I noted the resolution of the null pointer in the email section. That's
> great, thanks.
>
> Now, new issue (reported before but this time with more details): Email
> sent from a gmail account to a) another gmail account, b) an optusnet
> account (local cable ISP). Email contained a one line body text and an
> approx 4K text file attachment.
>
> Result: in both cases the file transaction looked like completing normally,
> the text part of the email was available in the inbox, but:
>
> 1. The attachment file was created in the files directory under the pskmail
> directory, but it was of zero size.
>
> 2. The transaction file in the pending directory was still there and could
> be decoded properly after a base64 decode and a zip decompression. Attached
> is that decompressed file for debug.
>
> 3. I also noted that A) the client send the proper FA block and the sever
> deletes the transaction as expected, B) the transaction file is locked on
> the client machine until I disconnect the session (no reading of the file
> and no deletion possible). Maybe that is why it is not deleted.
>
> This generates an "incomplete upload: 2" message at next connect. That also
> raises the question about the upload versus download wording.
>
>
> I repeated this exercise with another email containing and attached file
> and got the same result.
>
> I haven't tested the client under Linux.
>
> Also, the CQ block makes the server react as for a beacon which I think was
> the intent. I think that's pretty neat for client to server work as well as
> TTY. Good one.
>
> Testing the file section with client to server sessions:
>
> 1. The file progress being in the file window only is good. It keeps the
> terminal window clean. As noted in a previous email if we could do this for
> email downloads that would be great in my opinion.
>
> 2. I noted that the message "Requesting xyz" in the bottom left status of
> the client has a typo. Minor I know, but may as well be corrected.
>
> 3. File updates and downloads work well.
>
> 4. I haven't re-tested the partial file down/up-load and resume.
>
> 5. Proposed improvement: the "received file xyz" message in the terminal
> would be welcomed in the file window as well, so would the "file not found"
> message from the server when the file is not present there.
>
> 6. The "file stored" message appears in the file windows as well and that's
> great.
>
> 7. File uploads failed: I tested with a "QuickTime Player.lnk" file and got
> the following error on the server:
>
> *mv: target `Player.lnk' is not a directory*
> ::~FA:tmp357754500849010037
>
> So the server sees the transaction as complete but the move of the file
> fails on the file name because there is a space in the file name.
>
> I then tried with a no-space file without re-starting the server. And this
> resulted in the following error in the server log:
>
> gzip: /home/jdouyere/.pskmail/compressed already exists; do you wish to
> overwrite (y or n)?
>
> That highlights a major bug since no amount of connect/disconnect or
> connect/abort would allow the server to respond properly to new transactions
> (it would ignore the FO blocks).
>
> I restarted the server and this time it responded to the client FO blocks,
> but at the end of the file upload it failed again on the "do you wish to
> overwrite (y or n)?" situation.
>
> So that file needs to be cleaned up at session abort or quit and I would
> suggest at connect time for good measure, so at least if a previous
> transaction fails a disconnect/reconnect clears the temp file. I had to
> physically remove the "compressed" file in the .pskmail directory.
>
> Another issue: I send a file named "utils.cemenu" and the server happed to
> disconnect just at that time. Upon re-connect I pressed the "send" button to
> resume the upload. This is what the client then sent:
>
> ~FO5:VK2ETA-2:VK2ETA-3:tmp113875734864792506:u:mail:145
>
> Which has nothing to do with the file I was trying to send before. The
> "pending transaction" list in the client reports:
>
> Pending file uploads:
> VK2ETA-3:utils.cemenu:263
>
> Outbox:0
> Incomplete:0
>
> I checked the transaction file on the client and I see:
>
> >FM:VK2ETA-2:VK2ETA-3:tmp147aa2a38811434690:u:utils.cemenu:263
>
> So obviously it is not picking up the right file. In the outpending
> directory both transaction files exist, plus more. But only the one
> finishing in 690 is a valid unfinished transaction.
>
> That raises an issue about clean-up of pending transaction files, but that
> is probably for later.
>
> Not sure this is a good Christmas present..hihi
>
> But again if you have 3 meters of snow outside, it may not be that bad...I
> hope.
>
> Best regards,
>
> John
>
Other related posts:
