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--