Re: gnome-pilot and pilot-xfer restore don't work

[Adam C Powell IV <hazelsct debian org>]

Hello Matt,

Thanks for the reply.  My Treo just hard crashed again (shut down
completely, almost certainly blanked memory again), so I'll had another
"opportunity" to test again...

On Wed, 2007-05-02 at 18:06 +0100, Matt Davey wrote: 
> Hi Adam,
> 
> On Wed, 2007-05-02 at 08:28 -0400, Adam C Powell IV wrote:
> > Hello again,
> > 
> > [gnome-pilot specific so I'm not copying pilot-link-devel]
> > 
> > On Mon, 2007-04-30 at 07:28 -0400, Adam C Powell IV wrote:
> > > Greetings,
> > > 
> > > I'm having trouble restoring a Treo 600 (PalmOS V5.2H) using gnome-pilot
> > > and pilot link in Debian etch (2.0.15-2 and 0.12.1-5 respectively).
> > > 
> > > First, the Restore... menu item in the gnome-pilot applet menu seems
> > > completely useless.  The ellipsis suggests a follow-on dialog, but there
> > > is none, nor any menu item check, nor any other indication that it has
> > > been selected.  Furthermore, whether I use it or not, it tries to sync
> > > the pilot, unless it has just been blanked, in which case it tries to
> > > restore it, so Restore... has no discernible effect whatsoever.
> 
> It's embarrassing to admit (as I'm the gnome-pilot maintainer...), but I
> don't think I've ever tried the 'Restore...' applet option.  I'm not
> sure what it's supposed to do: possibly it's supposed to allow you to
> choose which backed-up state to restore onto the next device to connect
> -- i.e. click 'Restore', then you're invited to sync a device and it'll
> get overwritten with the previously backed-up data.  But don't quote me
> on that.

That's what I thought as well, but clicking "Restore..." does nothing
right away, the sync behavior is independent of whether I click it.

> > > Second, gnome-pilot always hangs while restoring the device, going up to
> > > 100% CPU and sitting there until the Treo times out.  If I move aside
> > > the file which seemed to cause this, it hangs on another file, and so
> > > on.  This behavior is identical to that reported by Krzysztof Porowski
> > > four years ago, and nobody followed up to his questions, nor has this
> > > problem been addressed since.  This is also Debian bug #146346 reported
> > > five years ago next week, and forwarded to this list, but with no
> > > helpful or corrective replies.  gnome-pilot restore is very broken.
> 
> ... in your case, certainly.  I have used the restore feature several
> times recently without problems.  I wasn't aware of this bug, and would
> be a bit surprised if it was entered into gnome-pilot bugzilla.  I don't
> know what's at the root of the problem, but will try to reproduce it
> myself for starters.  As I said, I've definitely had recent success with
> restore to a palmv over serial a connection.

Thanks for the data point.  Perhaps there are a handful of us with our
devices in a certain oddball state which triggers this... ?

> > My Treo hard crashed again yesterday (replacement on the way), so I got
> > a chance to try this out with strace.  It is hanging on "Installing
> > Blazer Cache..." and strace leading up to that shows:
> > 
> > open("/home/hazelsct/MyNewPilot/Blazer Cache.pdb", O_RDONLY) = 41
> > fstat64(41, {st_mode=S_IFREG|0644, st_size=2821647, ...}) = 0
> > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6c8e000
> > fstat64(41, {st_mode=S_IFREG|0644, st_size=2821647, ...}) = 0
> 
> [...]
> 
> > select(40, [39], NULL, NULL, {30, 0})   = 1 (in [39], left {30, 0})
> > read(39, "\1\253\0\0\0\n", 6)           = 6
> > select(40, [39], NULL, NULL, {30, 0})   = 1 (in [39], left {30, 0})
> > read(39, "\241\1\0\0 \4\0`\240\0", 10)  = 10
> > writev(38, [{"GIOP\1\2\1\0\200\0\0\0", 12}, {"\220\220\324\277\0\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0c\274"..., 128}], 2) = 140
> > _llseek(41, 36864, [36864], SEEK_SET)   = 0
> > _llseek(41, 36864, [36864], SEEK_SET)   = 0
> > _llseek(41, 36864, [36864], SEEK_SET)   = 0
> > _llseek(41, 36864, [36864], SEEK_SET)   = 0
> > _llseek(41, 36864, [36864], SEEK_SET)   = 0
> > _llseek(41, 36864, [36864], SEEK_SET)   = 0
> > 
> > then the llseek() repeats indefinitely.  If I move Blazer Cache out of
> > the way, it hangs on another file.
> > 
> > Any ideas?
> 
> Have you tried using a different connection type?  Try a network sync,
> if you can configure that with your Treo.  Failing that, have you tried
> both a libusb sync and a usbserial sync?

I had been using usbserial.  I just switched to the "usb:" device and
tried again, but this dialog came up:
        Failed to connect using device `Cradle' on port `usb:'.  Check
        your configuration, as you requested new-style libusb `usb:'
        syncing, but have the old-style `visor' kernel module loaded.
        You may need to select a `ttyUSB...' device.
I tried "rmmod visor" but got the same dialog again.

How do I try libusb in Debian?  Is udev automatically assigning visor to
this?

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html