[pskmail] More tests - client to server only this time

  • From: John Douyere <vk2eta@xxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Wed, 22 Dec 2010 13:56:59 +1100

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
Date: Wed, 22 Dec 2010 11:36:11 +1100
Subject: Test 2 - 22-Dec-2010
From: John Douyere <vk2eta@xxxxxxxxx>


--20cf30433ec89b2aa80497f4f036
Content-Type: multipart/alternative; boundarycf30433ec89b2a8a0497f4f034


--20cf30433ec89b2a8a0497f4f034


Test attachment under windows


--20cf30433ec89b2a8a0497f4f034


Test attachment under windows<div><br></div><div><br></div>


--20cf30433ec89b2a8a0497f4f034--
--20cf30433ec89b2aa80497f4f036
Content-Disposition: attachment; filename="crapmail.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ghzhtcpf0


VGhpcyBtZXNzYWdlIGlzIGluIE1JTUUgZm9ybWF0ClRoaXMgaXMgYSBtdWx0aS1wYXJ0IG1lc3Nh
Z2UgaW4gTUlNRSBmb3JtYXQKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOwpDb250ZW50LVRyYW5z
ZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlCk5leHRQYXJ0CmNoYXJzZXQ9CmJvdW5kYXJ5
PQotLUJvdW5kYXJ5Cmh0dHA6Ly93d3cubHljb3MuZGUvc3RhcnRzZWl0ZS9vbmxpbmUvZHNsCkJl
bmFjaHJpY2h0aWd1bmcgYmVpIEUtTWFpbCBFbXBmYW5nIQpSUkRYQSBtYWlsaW5nIGxpc3QKUlJE
WEFAbWFpbG1hbi5xdGgubmV0Cmh0dHA6Ly9tYWlsbWFuLnF0aC5uZXQvbWFpbG1hbi9saXN0aW5m
by9ycmR4YQoxMCBHQiBNYWlsYm94LCAxMDAgRnJlZVNNUy9Nb25hdCBodHRwOi8vd3d3LmdteC5u
ZXQvZGUvZ28vdG9wbWFpbApHTVggLSBkaWUgZXJzdGUgQWRyZXNzZSBmw7xyIE1haWwKLS0tLS1V
cnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQpUaXJlZCBvZiBzcGFtCmh0dHA6Ly9tYWlsLnlh
aG9vLmNvbSAKSEZwYWNrIFdlYnNpdGU6IGh0dHA6Ly9oZnBhY2suY29tCkFQUnBhY2sgZWdyb3Vw
IG1lc3NhZ2VzIGFyZQpZYWhvbyEgR3JvdXBzIExpbmtzClRvIHZpc2l0IHlvdXIgZ3JvdXAgb24g
dGhlIHdlYiwgZ28gdG86Cmh0dHA6Ly9ncm91cHMueWFob28uY29tL2dyb3VwL2FwcnBhY2svClRv
IHVuc3Vic2NyaWJlIGZyb20gdGhpcyBncm91cAphcHJwYWNrLXVuc3Vic2NyaWJlQHlhaG9vZ3Jv
dXBzLmNvbQpZb3VyIHVzZSBvZiBZYWhvbyEgR3JvdXBzIGlzIHN1YmplY3QgdG86Cmh0dHA6Ly9k
b2NzLnlhaG9vLmNvbS9pbmZvL3Rlcm1zLwpUbGYtZGV2ZWwgbWFpbGluZyBsaXN0ClRsZi1kZXZl
bEBub25nbnUub3JnCmh0dHA6Ly9saXN0cy5ub25nbnUub3JnL21haWxtYW4vbGlzdGluZm8vdGxm
LWRldmVsCk1JTUUtVmVyc2lvbjoKLS09PQpTdHV1ciBzdWJzY3JpYmUKL2dyb3Vwcy55YWhvby5j
b20vZ3JvdXAvRVNSQUMvCkVTUkFDLXVuc3Vic2NyaWJlCmh0dHA6Ly9ncm91cHMueWFob28uY29t
L2dyb3VwL0VTUkFDLwp1bmQgMyBNb25hdGUga29zdGVubG9zIGFiCm1haWxfZm9vdGVydHh0ClRo
aXMgaXMgYSBNSU1FCjwqPiBZb3VyIGVtYWlsIHNldHRpbmdzOgpJbmRpdmlkdWFsIEVtYWlsIHwg
VHJhZGl0aW9uYWwKPCo+IFRvIGNoYW5nZSBzZXR0aW5ncyBvbmxpbmUgZ28gdG86CllhaG9vISBJ
RCByZXF1aXJlZAo8Kj4gVG8gY2hhbmdlIHNldHRpbmdzIHZpYSBlbWFpbDoKbWFpbHRvOmFwcnBh
Y2stZGlnZXN0QHlhaG9vZ3JvdXBzLmNvbQptYWlsdG86YXBycGFjay1mdWxsZmVhdHVyZWRAeWFo
b29ncm91cHMuY29tCk5lZWQgYSBEaWdpdGFsIG1vZGUgUVNPCk90aGVyIGFyZWFzIG9mIGludGVy
ZXN0OgpUaGUgTWl4VyBSZWZsZWN0b3IgOiBodHRwOi8vZ3JvdXBzLnlhaG9vLmNvbS9ncm91cC90
aGVtaXh3Z3JvdXAvCkRpZ2lQb2w6IGh0dHA6Ly9ncm91cHMueWFob28uY29tL2dyb3VwL0RpZ2lw
b2wKaHR0cDovL2dyb3Vwcy55YWhvby5jb20vZ3JvdXAvZGlnaXRhbHJhZGlvLwpodHRwOi8vZ3Jv
dXBzLnlhaG9vLmNvbS9ncm91cC9kaWdpdGFscmFkaW8vam9pbgptYWlsdG86ZGlnaXRhbHJhZGlv
LWRpZ2VzdEB5YWhvb2dyb3Vwcy5jb20KbWFpbHRvOmRpZ2l0YWxyYWRpby1mdWxsZmVhdHVyZWRA
eWFob29ncm91cHMuY29tCmRpZ2l0YWxyYWRpby11bnN1YnNjcmliZUB5YWhvb2dyb3Vwcy5jb20K
VXNpbmcgVG9tY2F0IGJ1dCBuZWVkIHRvIGRvIG1vcmU/Cmh0dHA6Ly9zZWwuYXMtdXMuZmFsa2Fn
Lm5ldC9zZWw/Y21kPWxuayZraWQ9MTIwNzA5JmJpZD0yNjMwNTcmZGF0PTEyMTY0MgpHZXQgc3R1
ZmYgZG9uZSBxdWlja2x5IHdpdGggcHJlLWludGVncmF0ZWQgdGVjaG5vbG9neSB0byBtYWtlIHlv
dXIgam9iIGVhc2llcgpEb3dubG9hZCBJQk0gV2ViU3BoZXJlIEFwcGxpY2F0aW9uIFNlcnZlciB2
LjEuMC4xIGJhc2VkIG9uIEFwYWNoZSBHZXJvbmltbwpIYW1saWItZGV2ZWxvcGVyIG1haWxpbmcg
bGlzdApIYW1saWItZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldApodHRwczovL2xpc3Rz
LnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9oYW1saWItZGV2ZWxvcGVyCmh0dHA6Ly9n
cm91cHMueWFob28uY29tL2dyb3VwL2xpbnV4aGFtLwpodHRwOi8vZ3JvdXBzLnlhaG9vLmNvbS9n
cm91cC9saW51eGhhbS9qb2luCm1haWx0bzpsaW51eGhhbS1kaWdlc3RAeWFob29ncm91cHMuY29t
IAptYWlsdG86bGludXhoYW0tZnVsbGZlYXR1cmVkQHlhaG9vZ3JvdXBzLmNvbQpsaW51eGhhbS11
bnN1YnNjcmliZUB5YWhvb2dyb3Vwcy5jb20KVGhhbmtzIGZvciB1c2luZyBTYWlsZG9jcywgYW4g
SW50ZXJuZXQgZG9jdW1lbnQgcmV0cmlldmFsIApzZXJ2aWNlIGZvciB0aGUgYmFuZHdpZHRoLWlt
YWlyZWQuICAKU2FpbGRvY3MgaXMgcHJvdmlkZWQgd2l0aG91dCBjaGFyZ2UgdGhhbmtzIHRvIHRo
ZSBzdXBwb3J0IG9mIFNhaWxtYWlsLCAKYSBtZW1iZXJzaGlwLW93bmVkIHJhZGlvIGVtYWlsIHNl
cnZpY2UgZm9yIGNydWlzaW5nIHNhaWxvcnMgd2hpY2ggCm9wZXJhdGVzIGEgc2VhbWxlc3MgbmV0
d29yayBvZiAxMyBzdGF0aW9ucyB3b3JsZC13aWRlIFwoaW5jbHVkaW5nIApmaXZlIGNvdmVyaW5n
IHRoZSBDYXJpYmVhbiBhbmQgQXRsYW50aWNcKS4gRm9yIG1vcmUgaW5mb3JtYXRpb24gb24gClNh
aWxNYWlsIHNlZSB0aGUgd2ViIHBhZ2UgYXQgd3d3LnNhaWxtYWlsLmNvbSBvciBzZW5kIGEgcXVl
cnkgdG8gCnRoZSBvZmZpY2UgYXQgc3lzb3BAc2FpbG1haWwuY29tLiAKTW9yZSBpbmZvcm1hdGlv
biBvbiBTYWlsZG9jcyBpcyBhdmFpbGFibGUgYnkgc2VuZGluZyBhbiBlbWFpbCB0byAKaW5mb0Bz
YWlsZG9jcy5jb20sIHRoaXMgd2lsbCByZXR1cm4gdGhlIGhvdy10byBkb2N1bWVudCAoYWJvdXQg
NUspLiAK
--20cf30433ec89b2aa80497f4f036--

Other related posts: