Menu
▾
▴
#62 Can not access Series 3c using plpfuse
I could always access my Series 3c successfully using plpnfsd. However, today I came to compile the new PLP Tools as the old one doesn't compile on my system, only to discover plpnfsd has been replaced with plpfuse. After figuring out that I needed to install fuse before compiling, I tried it out. I can view my M:, but I can't access any files - it says Input/output error.
With debug, I get:
unique: 37, error: -5 (Input/output error), outsize: 16
unique: 38, opcode: READ (15), nodeid: 5, insize: 64
READ[0] 4096 bytes from 0
unique: 38, error: -5 (Input/output error), outsize: 16
unique: 39, opcode: FLUSH (25), nodeid: 5, insize: 64
FLUSH[0]
unique: 39, error: -38 (Function not implemented), outsize: 16
unique: 40, opcode: RELEASE (18), nodeid: 5, insize: 64
RELEASE[0] flags: 0x8000
unique: 40, error: 0 (Success), outsize: 16
Logged In: YES
user_id=661960
Originator: YES
I've now tried 0.16, and that compiles on my Fedora system and (thankfully) still uses plpnfsd. All my old scripts for connecting and backup now work as they should!
Logged In: YES
user_id=50145
Originator: NO
I'm sorry plpfuse doesn't work for you. Does the latest version's plpftp still work? It would be nice to know where the bug is. Unfortunately I don't have an EPOC16 device to test with.
Logged In: YES
user_id=661960
Originator: YES
plpftp just does nothing. It doesn't run any ftp comments passed as parameters or give a prompt.
Logged In: YES
user_id=50145
Originator: NO
If you turn on debugging for ncpd do you get anything in the relevant error log (for me it's /var/log/debug)? If plpftp doesn't work it suggests the problem is not in plpfuse. I presume that plpftp at least prints a startup message? Does it not give any error?
Logged In: YES
user_id=50145
Originator: NO
Could you possibly discover which is the earliest version that doesn't work? I think that would be the quickest way for me to find a likely fix; as far as I can see there have been no non-trivial changes to the ncpd code since 0.16, so the bug is probably in some seemingly trivial change. I would suggest a binary search, i.e. try version 1.0.0 first, then work backwards or forwards as necessary, roughly skipping half the versions each time.
Logged In: YES
user_id=661960
Originator: YES
I'll do that, but maybe not today - I'm curently backing up my computer, which was why I wanted the Psion backup first. Which was the first version to use plpfuse instead of plpnfsd?
Logged In: YES
user_id=50145
Originator: NO
That would be great. 0.19 is the first version with plpfuse, but as I said, I doubt that's relevant (although it's of course possible that it has other problems with Series 3). I would try plpftp in each case.
Could you try the latest release? The workaround for a Series 3a bug may apply to 3c too.
I hit this problem yesterday when for the first time I used plpfuse (as against the old plpnfsd) when trying to access my Psion 3mx. Googling, I found this thread indicating this problem has been outstanding for quite a few years. Anyway had a go at cracking it.
After downloading and compiling the code, I added a few extra debug messages, to help me identify the problem.
The a->fseek in rfsv_read on line 240 of plpfuse/main.cc was returning error code '-45' which according to:
http://www.augusta.de/~michael/BeOS/PalmBeach/protokoll/rfsv/fseek.us.html
means Invalid IO-Function. Appears, when the file wasn't opened with FRANDOM! which gave a major clue. The same website gives various mode settings for the fopen command, one of which provides random access:
http://www.augusta.de/~michael/BeOS/PalmBeach/protokoll/rfsv/fopen.us.html
Working through the plptools sources found a way to override the default in rfsv16::fopen function in lib/rfsv16.cc on line 58, changing it from:
to:
Basically it enables random seeks of files on the psion. Tested it out with reads and writes to my 3mx, which is a faster version of the Psion 3C Jonathan had problems with .
Hope this helps.
Peter, this is great stuff! However, it's odd, as I can't see why plpnfsd wouldn't've been affected in exactly the same way, unless for some reason it never tried to read from the middle of a file. (The code worked the same way; indeed, plpfuse is mostly copied from plpnfsd.)
I've pushed your fix to git; can you possibly build from git and confirm that it works?
Ticket moved from /p/plptools/support-requests/20/
Reuben, thanks for picking this ancient bug up. I did a "git clone" and looked at the source change you made to rfsv16::fopen in lib/rfsv16.cc it's spot on.
I was not able to build a binary to test -- probably, me being a bit rusty on using git, but, I could not find a ./configure to run and create the Makefile. To grab the clone is used the command suggested under the code tab for plptools, viz:
As to why the old plpnfsd worked, I did have a quick look. Not studied it in depth. It looks like plpnfsd possibly pulled a full copy over the link from the Psion and cached it.
Also plpftp worked fine, but when I looked in the 1.0.12 sources it only uses sequential access, which is not surprising for an ftp emulation.
On 6 July 2014 19:58, Peter Maud petemaud@users.sf.net wrote:
As documented at the bottom of INSTALL, you need to run "autoreconf -i"
first. Could I make it more obvious? I hope that helps you test it, and
thanks very much for both trying and reporting your difficulties!
Thanks for the pointer to autoreconf, but, I had a bit of a problem with that too. It error-ed out complaining:
Looking at the comments on the sf master tree, I see mention of a recent change to subdirectory "doc". Comparing with earlier editions it no longer has "doc/api" in it. So, edited "configure.ac" and in the "AC_CONFIG_FILES" list deleted line 246 "doc/api/Makefile". After that "autoreconf", "configure" and "make" all ran to completion.
Anyway back to the purpose of the exercise...
The plpfuse test was successful: fired up the newly built "ncpd" and "plpfuse" then copied files to and from my Psion 3mx. Did some md5sums on round trip copies which showed there'd been no data corruption.
Thanks very much for the test and the extra bug report, which was as you
suspected an oversight when I removed the doc/api directory (the KDE tool
used to generate the HTML API documentation no longer exists in current
KDE).
On 7 July 2014 10:20, Peter Maud petemaud@users.sf.net wrote:
--
http://rrt.sc3d.org
Peter, Reuben, thanks a lot for fixing this bug. I retired my 3c a couple of years ago when I went over exclusively to Android, but it's great to see old projects like this still being supported for people who want to keep their much loved, old hardware going.